Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Riena » Embedded Objects - Value Objects
Embedded Objects - Value Objects [message #1560] Mon, 19 May 2008 19:58 Go to next message
Eclipse UserFriend
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 #1642 is a reply to message #1560] Tue, 20 May 2008 10:53 Go to previous messageGo to next message
Christian Campo is currently offline Christian CampoFriend
Messages: 590
Registered: July 2009
Senior Member
You are hoping too much :-(

Properties like String, int and else of course cant implement ITransactedObject. Your other embedded objects
should implement ITransactedObject. The reason is that you also want for those objects to track if properties
are changing. Just consider this code

customer.getAddress().setZipcode(60000)

How can OT track this change. The customer class does not know about this change, so it does not track it. So it
has to happen in the Address class in their setter. Setting the zipcode is a property of the Address object.

customer.setAddress(someExistingAddress)

is setting a reference to another object. "someExistingAddress" is not for OT a property but its maintained to
another transactedobject (the address).

If these objects dont have a PK in your database, maybe you can come up with some other kind of identity. Maybe
derived from the PK of the customer. Not sure.

But as OT is running today:

Customer and Address both have to implement ITransactedObject, both have to be registered in your ObjectTransaction
in order to run. Both have to contain some code in their setters and getters to track changes, either by adding that
code or by an aspect.

Hope that clears things up.

christian


ekke schrieb:
> 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 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Christian Campo is currently offline Christian CampoFriend
Messages: 590
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 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Eclipse UserFriend
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 #3021 is a reply to message #2866] Mon, 26 May 2008 11:22 Go to previous messageGo to next message
Christian Campo is currently offline Christian CampoFriend
Messages: 590
Registered: July 2009
Senior Member
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.

considering the embedded objects you also have to set the version or they automatically read the version from
the parent. in any event you can do that on the server, and use the delta mechanism that will propagate them to
the client.

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

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 #3039 is a reply to message #3021] Mon, 26 May 2008 17:52 Go to previous message
Eclipse UserFriend
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 #570736 is a reply to message #1560] Tue, 20 May 2008 10:53 Go to previous message
Christian Campo is currently offline Christian CampoFriend
Messages: 590
Registered: July 2009
Senior Member
You are hoping too much :-(

Properties like String, int and else of course cant implement ITransactedObject. Your other embedded objects
should implement ITransactedObject. The reason is that you also want for those objects to track if properties
are changing. Just consider this code

customer.getAddress().setZipcode(60000)

How can OT track this change. The customer class does not know about this change, so it does not track it. So it
has to happen in the Address class in their setter. Setting the zipcode is a property of the Address object.

customer.setAddress(someExistingAddress)

is setting a reference to another object. "someExistingAddress" is not for OT a property but its maintained to
another transactedobject (the address).

If these objects dont have a PK in your database, maybe you can come up with some other kind of identity. Maybe
derived from the PK of the customer. Not sure.

But as OT is running today:

Customer and Address both have to implement ITransactedObject, both have to be registered in your ObjectTransaction
in order to run. Both have to contain some code in their setters and getters to track changes, either by adding that
code or by an aspect.

Hope that clears things up.

christian


ekke schrieb:
> 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 #570801 is a reply to message #1642] Tue, 20 May 2008 11:24 Go to previous message
Eclipse UserFriend
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 Go to previous message
Eclipse UserFriend
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 Go to previous message
Christian Campo is currently offline Christian CampoFriend
Messages: 590
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 Go to previous message
Eclipse UserFriend
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 Go to previous message
Eclipse UserFriend
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 #571547 is a reply to message #2866] Mon, 26 May 2008 11:22 Go to previous message
Christian Campo is currently offline Christian CampoFriend
Messages: 590
Registered: July 2009
Senior Member
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.

considering the embedded objects you also have to set the version or they automatically read the version from
the parent. in any event you can do that on the server, and use the delta mechanism that will propagate them to
the client.

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

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 #571582 is a reply to message #3021] Mon, 26 May 2008 17:52 Go to previous message
Eclipse UserFriend
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
>>
Previous Topic:riena server outside eclipse
Next Topic:new objects and IObjectID
Goto Forum:
  


Current Time: Mon Nov 24 18:15:14 GMT 2014

Powered by FUDForum. Page generated in 0.02441 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software