Re: getAllReferencingObjects(Object object) request

[Craig L Russell]

Hi Christiaan,

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

Hi Craig,






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?

"We actually have changed the specification in this regard, so that if

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

Yes.

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:


the columns of this foreign key. Some databases do not support this
action.>

Unfortunately, the database I am using doesn't support this.

<null: If the referenced row is deleted or changes its primary key, null

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

that getAllReferencingObjects() could be a handy method in doing this

it would also be less maintenance sensitive.

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 and would not only save the developer time in writing this code himself

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.

Right.

With the available

or he has to maintain his own implementation of
getAllReferencingObjects()?

solutions he either has to maintain the update semantics in the metadata

Regards,

Craig

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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature