| Embedded Objects - Value Objects [message #1560] |
Mon, 19 May 2008 19:58  |
Eclipse User |
|
|
|
Originally posted by: ekkehard.gentz-software.de
All BOs have to implement ITransactedObject
so all my @EMBEDDED objects are properties for the ObjectTransaction -
this is right ?
BO Customer
Embedded Address homeAdr
Embedded Address businessAdr
Adress has some String and int Properties
are all these Properties from embedded objects managed by
ObjectTransaction ?
they have no own DB identity - and so they have no PK
and I hope I dont have to implement ITransactedObject for @EMBEDDED too
ekke
|
|
|
|
| Re: Embedded Objects - Value Objects [message #1663 is a reply to message #1642] |
Tue, 20 May 2008 11:24  |
| Eclipse User |
|
|
|
Originally posted by: ekkehard.gentz-software.de
Christian, I understand...
I can construct a unique identity for the embedded classes,
to make equals() and hashcode() happy:
I already have to construct the column name for the database,
something like
CUST_HOME_STREET
CUST_HOME_CITY
CUST_BUSINESS_STREET
CUST_BUSINESS_CITY
so I can use this as unique value
fortunately I generate all my code from openArchitectureWare templates and
I can easy change it to generate these equals() and hashCode()
so the identity and the type is no problem
the version will always be the same as the 'parent' class version,
because they always will be stored at the same time
as I told you @EMBEDDED has no own database identity
but this means, after storing the 'parent' JPA/Hibernate will increment
the version.
imagine I only change attributes of Customer, but no attributes of home-
or business address. then for OT only Customer was changed and stored.
so there will be some trouble with export / import between server and
client, I can imagine. I have to propagate the new version numbers to the
address objects at client side.
ekke
|
|
|
| Re: Embedded Objects - Value Objects [message #1685 is a reply to message #1663] |
Tue, 20 May 2008 11:29 |
| Eclipse User |
|
|
|
Originally posted by: ekkehard.gentz-software.de
or do I have to do something like a 'refresh' of the registered adress
objects at client side ? then OT will get the new version()
ekke
ekke wrote:
> so there will be some trouble with export / import between server and
> client, I can imagine. I have to propagate the new version numbers to the
> address objects at client side.
> ekke
|
|
|
| Re: Embedded Objects - Value Objects [message #2772 is a reply to message #1685] |
Tue, 20 May 2008 15:24 |
 Christian Campo
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
what you basically do is that after the object got loaded from the database, they got registered,
the delta is imported. now you have the same version of everything client and server.....
now call commitToObjects. The deltas are actually applied to the bean properties, delta is empty....
If in the process of storing versions change or other properties are changed, the OT is filled with modifications,
you extract a delta, return it to the client and there again you now know the client delta was stored, commitToObjects
to apply the client changes, import server delta and commitToObjects again and apply these to the objects again.
Then you have a clean object transaction and all your beans contain the versions from the server
christian
ekke schrieb:
> or do I have to do something like a 'refresh' of the registered adress
> objects at client side ? then OT will get the new version()
>
> ekke
>
> ekke wrote:
>
>> so there will be some trouble with export / import between server and
>> client, I can imagine. I have to propagate the new version numbers to
>> the address objects at client side.
>
>> ekke
>
>
|
|
|
| Re: Embedded Objects - Value Objects [message #2790 is a reply to message #2772] |
Tue, 20 May 2008 15:55 |
| Eclipse User |
|
|
|
Originally posted by: ekkehard.gentz-software.de
christian,
what about this:
Customer c1 version 1.0
Address a1 (is homeAdress of c1 and @EMBEDDED)
a1 has no own version
a1.version() is in real a1.c1.version() = 1.0
register c1 and a1 with OT
now I change an attribute of c1
...
delta goes to server
...
stores it in DB, so c1.version() now is 1.1
...goes back to the client
...comitToObjects commits the changes of c1 into c1
a1 wasn't changed
if I now ask a1, the version also is 1.1
because it gets it from c1
is this ok for OT ?
as I registered a1 the first time, it was 1.0
hope, its not confusing you ;-)
ekke
|
|
|
| Re: Embedded Objects - Value Objects [message #2866 is a reply to message #2790] |
Tue, 20 May 2008 20:10 |
| Eclipse User |
|
|
|
Originally posted by: ekkehard.gentz-software.de
Christian,
forget my last msg - I replied too fast
after reading your last msg carefully I understood
- all changes from client and server
are back at client site propagated to the bean properties
together with the new version from server.
I think my missing point was this:
I read that I have to propagate version-change to the OT
using ObjectTransaction.setVersionUpdate()
am I right that I have to setVersionUpdate() after getting
the new version from Hibernate - database - commit ?
then - at client site - for all my embedded objects I also
have to set the new version from the 'parent'
ekke
|
|
|
|
| Re: Embedded Objects - Value Objects [message #3039 is a reply to message #3021] |
Mon, 26 May 2008 17:52 |
| Eclipse User |
|
|
|
Originally posted by: ekkehard.gentz-software.de
Christian Campo wrote:
> if you do setVersionUpdate() on the server for an object, that is considered
a change of a property,
> in this case the change of a "system property" of the object (same as object
id). so that change gets into
> the delta. if you send the delta from server to client that gets
automatically applied.
OK
> If the embedded version always have the same version as the parent object
(because they are stored in a single record
> in the database), I recommend that the parent calls in this setVersion
method, the setVersion method in all his child
> objects.
> Does that make sense for you
I'm using JPA / Hibernate with Annotations
all Annotations are at field level
so Hibernate sets the version (field) automagically
there's no setter - only a getter (normally)
so I'll add a private setter for the version in @Embedded Objects
(used by OT to update the client from server delta)
the versions of the embedded objects are always the same as from parent,
so I have to set them after updating the database where Hibernate updates
the version of the parent
and to not confuse JPA/Hibernate the version field on @Embedded will
be annotated with @Transient (this means: non-transient for java -
because the web-service has to serialize it, but transient for
JPA/Hibernate,
as it will not persisted in database)
ekke
> christian campo
> ekke schrieb:
>> Christian,
>>
>> forget my last msg - I replied too fast
>>
>> after reading your last msg carefully I understood
>> - all changes from client and server
>> are back at client site propagated to the bean properties
>> together with the new version from server.
>>
>> I think my missing point was this:
>>
>> I read that I have to propagate version-change to the OT
>> using ObjectTransaction.setVersionUpdate()
>>
>> am I right that I have to setVersionUpdate() after getting
>> the new version from Hibernate - database - commit ?
>>
>> then - at client site - for all my embedded objects I also have to set
>> the new version from the 'parent'
>>
>> ekke
>>
|
|
|
|
| Re: Embedded Objects - Value Objects [message #570801 is a reply to message #1642] |
Tue, 20 May 2008 11:24 |
| Eclipse User |
|
|
|
Originally posted by: ekkehard.gentz-software.de
Christian, I understand...
I can construct a unique identity for the embedded classes,
to make equals() and hashcode() happy:
I already have to construct the column name for the database,
something like
CUST_HOME_STREET
CUST_HOME_CITY
CUST_BUSINESS_STREET
CUST_BUSINESS_CITY
so I can use this as unique value
fortunately I generate all my code from openArchitectureWare templates and
I can easy change it to generate these equals() and hashCode()
so the identity and the type is no problem
the version will always be the same as the 'parent' class version,
because they always will be stored at the same time
as I told you @EMBEDDED has no own database identity
but this means, after storing the 'parent' JPA/Hibernate will increment
the version.
imagine I only change attributes of Customer, but no attributes of home-
or business address. then for OT only Customer was changed and stored.
so there will be some trouble with export / import between server and
client, I can imagine. I have to propagate the new version numbers to the
address objects at client side.
ekke
|
|
|
| Re: Embedded Objects - Value Objects [message #570866 is a reply to message #1663] |
Tue, 20 May 2008 11:29 |
| Eclipse User |
|
|
|
Originally posted by: ekkehard.gentz-software.de
or do I have to do something like a 'refresh' of the registered adress
objects at client side ? then OT will get the new version()
ekke
ekke wrote:
> so there will be some trouble with export / import between server and
> client, I can imagine. I have to propagate the new version numbers to the
> address objects at client side.
> ekke
|
|
|
| Re: Embedded Objects - Value Objects [message #570955 is a reply to message #1685] |
Tue, 20 May 2008 15:24 |
Christian Campo
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
what you basically do is that after the object got loaded from the database, they got registered,
the delta is imported. now you have the same version of everything client and server.....
now call commitToObjects. The deltas are actually applied to the bean properties, delta is empty....
If in the process of storing versions change or other properties are changed, the OT is filled with modifications,
you extract a delta, return it to the client and there again you now know the client delta was stored, commitToObjects
to apply the client changes, import server delta and commitToObjects again and apply these to the objects again.
Then you have a clean object transaction and all your beans contain the versions from the server
christian
ekke schrieb:
> or do I have to do something like a 'refresh' of the registered adress
> objects at client side ? then OT will get the new version()
>
> ekke
>
> ekke wrote:
>
>> so there will be some trouble with export / import between server and
>> client, I can imagine. I have to propagate the new version numbers to
>> the address objects at client side.
>
>> ekke
>
>
|
|
|
| Re: Embedded Objects - Value Objects [message #571021 is a reply to message #2772] |
Tue, 20 May 2008 15:55 |
| Eclipse User |
|
|
|
Originally posted by: ekkehard.gentz-software.de
christian,
what about this:
Customer c1 version 1.0
Address a1 (is homeAdress of c1 and @EMBEDDED)
a1 has no own version
a1.version() is in real a1.c1.version() = 1.0
register c1 and a1 with OT
now I change an attribute of c1
...
delta goes to server
...
stores it in DB, so c1.version() now is 1.1
...goes back to the client
...comitToObjects commits the changes of c1 into c1
a1 wasn't changed
if I now ask a1, the version also is 1.1
because it gets it from c1
is this ok for OT ?
as I registered a1 the first time, it was 1.0
hope, its not confusing you ;-)
ekke
|
|
|
| Re: Embedded Objects - Value Objects [message #571220 is a reply to message #2790] |
Tue, 20 May 2008 20:10 |
| Eclipse User |
|
|
|
Originally posted by: ekkehard.gentz-software.de
Christian,
forget my last msg - I replied too fast
after reading your last msg carefully I understood
- all changes from client and server
are back at client site propagated to the bean properties
together with the new version from server.
I think my missing point was this:
I read that I have to propagate version-change to the OT
using ObjectTransaction.setVersionUpdate()
am I right that I have to setVersionUpdate() after getting
the new version from Hibernate - database - commit ?
then - at client site - for all my embedded objects I also
have to set the new version from the 'parent'
ekke
|
|
|
|
| Re: Embedded Objects - Value Objects [message #571582 is a reply to message #3021] |
Mon, 26 May 2008 17:52 |
| Eclipse User |
|
|
|
Originally posted by: ekkehard.gentz-software.de
Christian Campo wrote:
> if you do setVersionUpdate() on the server for an object, that is considered
a change of a property,
> in this case the change of a "system property" of the object (same as object
id). so that change gets into
> the delta. if you send the delta from server to client that gets
automatically applied.
OK
> If the embedded version always have the same version as the parent object
(because they are stored in a single record
> in the database), I recommend that the parent calls in this setVersion
method, the setVersion method in all his child
> objects.
> Does that make sense for you
I'm using JPA / Hibernate with Annotations
all Annotations are at field level
so Hibernate sets the version (field) automagically
there's no setter - only a getter (normally)
so I'll add a private setter for the version in @Embedded Objects
(used by OT to update the client from server delta)
the versions of the embedded objects are always the same as from parent,
so I have to set them after updating the database where Hibernate updates
the version of the parent
and to not confuse JPA/Hibernate the version field on @Embedded will
be annotated with @Transient (this means: non-transient for java -
because the web-service has to serialize it, but transient for
JPA/Hibernate,
as it will not persisted in database)
ekke
> christian campo
> ekke schrieb:
>> Christian,
>>
>> forget my last msg - I replied too fast
>>
>> after reading your last msg carefully I understood
>> - all changes from client and server
>> are back at client site propagated to the bean properties
>> together with the new version from server.
>>
>> I think my missing point was this:
>>
>> I read that I have to propagate version-change to the OT
>> using ObjectTransaction.setVersionUpdate()
>>
>> am I right that I have to setVersionUpdate() after getting
>> the new version from Hibernate - database - commit ?
>>
>> then - at client site - for all my embedded objects I also have to set
>> the new version from the 'parent'
>>
>> ekke
>>
|
|
|
Powered by
FUDForum. Page generated in 0.04616 seconds
] 
Search
Help
Register
Login
Home
