db-jdo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: getAllReferencingObjects(Object object) request
Date Wed, 20 Jun 2007 15:30:39 GMT
Hi Christiaan,

On Jun 20, 2007, at 1:19 AM, Christiaan des Bouvrie wrote:

> Hi Craig,
>  "We actually have changed the specification in this regard, so  
> that if
> you are using a mapping in which a single database artifact (e.g.
> primary key, foreign key) is used to describe two or more concepts,
> the deletion of an instance causes the cleanup of other instances
> that refer to that deleted instance."
> Can you tell me where this is described in the spec?

It's in 15.3. The JDO 2.1 update is currently:
If two relationships (one on each side of an association) are mapped  
to the same column, the field on only one side of the association  
needs to be explicitly mapped.
The field on the other side of the relationship can be mapped by  
using the mapped-by attribute identifying the field on the side that  
defines the mapping. Regardless of which side changes the  
relationship, flush (whether done as part of commit or explicitly by  
the user) will modify the datastore to reflect the change and will  
update the memory model for consistency. There is no further behavior  
implied by having both sides of the relationship map to the same  
database column(s). In particular, making a change to one side of the  
relationship does not imply any runtime behavior by the JDO  
implementation to change the other side of the relationship in memory  
prior to flush, and there is no requirement to load fields affected  
by the change if they are not already loaded. This implies that if  
the RetainValues flag or DetachAllOnCommit is set to true, and the  
relationship field is loaded, then the implementation will change the  
field on the other side so it is visible after transaction completion.
Conflicting changes to relationships cause a JDOUserException to be  
thrown at flush time. Conflicting changes include:
adding a related instance with a single-valued mapped-by relationship  
field to more than one one-to-many collection relationship
setting both sides of a one-to-one relationship such that they do not  
refer to each other

> Are you referring
> to the mapped-by attribute in JDO2
> to deal with updating of references


> or the delete/update action for foreign keys?

No, actions are a separate concern. These are intended to reflect the  
underlying database settings for the foreign keys.

> For the latter, the jdo
> implementation I am using has the following comment on this:
> <null: If the referenced row is deleted or changes its primary key,  
> null
> the columns of this foreign key. Some databases do not support this
> action.>
> Unfortunately, the database I am using doesn't support this.

The update in JDO 2.1 will cover the case of delete even if the  
delete action is not supported by the database itself.
> "Do all of your examples use delete as the cause of the issue?"
>  Most of them, but it could also be handy to maintain integrity when
> updating one-one relationships and one-to-many.

This is also addressed in 15.3. In JDO 2.1 we're looking to make it  
more clear what the behavior is for update and delete of instances  
that are related with the mappedBy relationships.

> Btw, with jdo1 the
> recommendation was to manually maintain all references, which is  
> fine by
> me, since you have that to do that in plain java as well. I just  
> thought
> that getAllReferencingObjects() could be a handy method in doing this
> and would not only save the developer time in writing this code  
> himself
> it would also be less maintenance sensitive.

Manually changing the relationships to reflect the change in the  
database seems like the wrong approach, since changing relationships  
requires instantiation of relationships simply for this purpose. And  
this is doing work for no real purpose since the database is already  
being updated.
> "Would it be better to describe the delete semantics instead of having
> the user worry about it?"
> Not sure what you mean with this. Who is the user in this case?

I meant the application developer.

> As I see it there is no user worrying about this, just the person  
> who is
> designing/implementing the persistent objects.


> With the available
> solutions he either has to maintain the update semantics in the  
> metadata
> or he has to maintain his own implementation of
> getAllReferencingObjects()?

Yes, and I think we're talking about making the metadata the better  
place to specify what happens on relationship updates.


> Regards,
> Christiaan

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

View raw message