You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-user@db.apache.org by Christiaan des Bouvrie <c....@CostEngineering.eu> on 2007/06/15 10:34:23 UTC
getAllReferencingObjects(Object object) request
Dear all,
I would like to make a feature request for a
getAllReferencingObjects(Object object) method, which should return a
set of pc objects which have a reference to the specified pc object.
This would be really convenient for instance when deleting an object to
make sure all references are set to null. In the domain I am working I
have a network of all kinds of objects where each object can be deleted
and thus all other objects have to update their reference. I currently
have a generic delete algorithm which recursively asks all (cascaded
deleted) objects to get their references in order to update them. Of
course, this method would also be quite convenient in unittest to make
sure you have updated everything properly.
Kind regards,
Christiaan
Fwd: getAllReferencingObjects(Object object) request
Posted by Craig L Russell <Cr...@Sun.COM>.
What do you all think of this?
Craig
Begin forwarded message:
> From: Christiaan des Bouvrie <c....@CostEngineering.eu>
> Date: June 15, 2007 1:34:23 AM PDT
> To: jdo-user@db.apache.org
> Subject: getAllReferencingObjects(Object object) request
> Reply-To: jdo-user@db.apache.org
>
> Dear all,
>
>
>
> I would like to make a feature request for a
> getAllReferencingObjects(Object object) method, which should return a
> set of pc objects which have a reference to the specified pc object.
>
>
>
> This would be really convenient for instance when deleting an
> object to
> make sure all references are set to null. In the domain I am working I
> have a network of all kinds of objects where each object can be
> deleted
> and thus all other objects have to update their reference. I currently
> have a generic delete algorithm which recursively asks all (cascaded
> deleted) objects to get their references in order to update them. Of
> course, this method would also be quite convenient in unittest to make
> sure you have updated everything properly.
>
>
>
> Kind 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!
RE: getAllReferencingObjects(Object object) request
Posted by "Matthew T. Adams" <ma...@xcalia.com>.
I actually discussed this a long time ago with Robin Roos, and we came to
the conclusion that this, as David points out, is a Java problem, not so
much a JDO one.
We considered starting a new JSR dedicated to the concept of bidirectional
reference management in Java, but we never filed it. Perhaps this is a good
time to pick this idea up again and reconsider. I have a sneaking suspicion
that this would be a change way down deep in the guts of Java more than just
a new api.
-matthew
-----Original Message-----
From: David Ezzio [mailto:dezzio@bea.com]
Sent: Friday, June 15, 2007 7:03 AM
To: jdo-user@db.apache.org
Subject: Re: getAllReferencingObjects(Object object) request
Hi Christiaan,
I agree your feature request would be convenient. But I don't see any
way to implement it that wouldn't be a design and performance nightmare.
Consider first all the design implications. Java, as you know, does not
have any such concept. For Java, it is unnecessary, since objects exist
as long as another uncollectable object refers to them. This is how Java
avoids, as you know, the dangling references of C++.
Then consider performance. The JDO implementation very likely has a set
of references to uncollected pc objects, but how would it determine that
one of these objects refers to the object in question? It would have to
reflect on all the fields and see if they have a reference that is
compatible with the type of the checked object and in fact refers to it.
If I understand your requirement, you have an a graph of objects where
you want to make any one of them go away. In Java, you would have to
update all objects that refer to the object to be removed. You have to
do the same when using JDO. The JDO implementation may give you a
vendor feature that might help. Some JDO implementations persistence
manager can give you a list of pc objects that they are managing. You
could run a query on this set of objects to determine which ones refer
to the object that you want to delete.
Cheers,
David Ezzo
Christiaan des Bouvrie wrote:
> Dear all,
>
>
>
> I would like to make a feature request for a
> getAllReferencingObjects(Object object) method, which should return a
> set of pc objects which have a reference to the specified pc object.
>
>
>
> This would be really convenient for instance when deleting an object to
> make sure all references are set to null. In the domain I am working I
> have a network of all kinds of objects where each object can be deleted
> and thus all other objects have to update their reference. I currently
> have a generic delete algorithm which recursively asks all (cascaded
> deleted) objects to get their references in order to update them. Of
> course, this method would also be quite convenient in unittest to make
> sure you have updated everything properly.
>
>
>
> Kind regards,
>
> Christiaan
>
>
>
>
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual or
entity named in this message. If you are not the intended recipient, and
have received this message in error, please immediately return this by email
and then delete it.
Re: getAllReferencingObjects(Object object) request
Posted by David Ezzio <de...@bea.com>.
Hi Christiaan,
I agree your feature request would be convenient. But I don't see any
way to implement it that wouldn't be a design and performance nightmare.
Consider first all the design implications. Java, as you know, does not
have any such concept. For Java, it is unnecessary, since objects exist
as long as another uncollectable object refers to them. This is how Java
avoids, as you know, the dangling references of C++.
Then consider performance. The JDO implementation very likely has a set
of references to uncollected pc objects, but how would it determine that
one of these objects refers to the object in question? It would have to
reflect on all the fields and see if they have a reference that is
compatible with the type of the checked object and in fact refers to it.
If I understand your requirement, you have an a graph of objects where
you want to make any one of them go away. In Java, you would have to
update all objects that refer to the object to be removed. You have to
do the same when using JDO. The JDO implementation may give you a
vendor feature that might help. Some JDO implementations persistence
manager can give you a list of pc objects that they are managing. You
could run a query on this set of objects to determine which ones refer
to the object that you want to delete.
Cheers,
David Ezzo
Christiaan des Bouvrie wrote:
> Dear all,
>
>
>
> I would like to make a feature request for a
> getAllReferencingObjects(Object object) method, which should return a
> set of pc objects which have a reference to the specified pc object.
>
>
>
> This would be really convenient for instance when deleting an object to
> make sure all references are set to null. In the domain I am working I
> have a network of all kinds of objects where each object can be deleted
> and thus all other objects have to update their reference. I currently
> have a generic delete algorithm which recursively asks all (cascaded
> deleted) objects to get their references in order to update them. Of
> course, this method would also be quite convenient in unittest to make
> sure you have updated everything properly.
>
>
>
> Kind regards,
>
> Christiaan
>
>
>
>
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.