Guillaume Nodet wrote:
Maybe using the Identity object's 'equals' method should solve the problem.
hmm, Identity should be ok, but it's much more costly than using object identity in this case.
I don't think the point here is on business objects equality. The point is to know if the object ojb is storing or deleting has already been processed or not for a given object graph. This can only be the case if the primary keys of the objects are the same (wether they are stored in the objects or anonymous).
There could be cases where two objects have the same primary keys, but are not the same object (in the sense of '=='). In theses case, and you are right about that, this would lead to problems.
What are the problems? If we delete the same object twice or more (same PK, but different instances), nothing should happend.
When we store different instances with same PK, first time an insert will happend, all further instances cause an update.
Do I overlook a fault?
regards, Armin
But using their associated Identity objects should be right.
Guillaume
-----Message d'origine----- De : Larry V. Streepy, Jr. [mailto:[EMAIL PROTECTED] Envoyé : jeudi 12 février 2004 16:35 À : OJB Users List Objet : Re: Bug in doDelete with the markedForDelete list
As I think about this thread, I'm beginning to wonder about the consequences of the changes being proposed. The essence of the problem revolves around the equality of business objects. The problem was that the equals() method returns true, even when they have different primary keys. This means that you truly have two different real objects, but for business reasons you want them to compare equals. So, from a business perspective, they are the same object, but you want multiple, distinct persisted forms.
So, are we now saying that object identity (using "==") is the mechanism that OJB will use in all cases, as opposed to object equality (using equals())? If so, is this what was originally intended in the OJB code? Further, is anyone relying on the current behavior?
Although it might make the code more complex, this might need to be a behavior that is configurable. Meaning that you would have to abstract the object equality comparisons and let them be controlled by specific implementations as needed by the business environment.
Just wanted to raise the questions because the change you are discussing is subtle, yet potentially very large in scope.
Thanks. Larry.
Armin Waibel wrote:
Hi,
Guillaume Nodet wrote:
Armin,
I dit not see any identity based List. There are Maps (in the jarakarta-commons-collections for exemple) and a Set could be easily build on top of this map.
Maybe just inlining the contains function directly in the doDelete function, walking through the array should do the work.
Thanks, I will do this, but encapsulate it in a new class, because I assume that we need such an function on store method too (nowStoring List).
regards, Armin
Guillaume
-----Message d'origine----- De : Armin Waibel [mailto:[EMAIL PROTECTED] Envoyé : mercredi 11 février 2004 19:14 À : OJB Users List Objet : Re: Bug in doDelete with the markedForDelete list
Hi Guillaume,
Guillaume Nodet wrote:
Another way could be to use a specific Map that test an object equality
with
a '==' instead of a 'equals'.
agree, seems to be the smartest way to get around your problem. Do you know an object identity based ArrayList/List implementation?
regards, Armin
Guillaume
-----Message d'origine----- De : Guillaume Nodet [mailto:[EMAIL PROTECTED] Envoyé : mercredi 11 février 2004 12:22 À : OJB Objet : Bug in doDelete with the markedForDelete list
Hi Armin !
I've found a problem using objects instead of Identity in the markedForDelete list of PersistenceBrokerImpl class. Here is my problem:
I want to delete an object A that contains a collection of B objects. When i put 2 B objects that are equals in my collection, and trying to delete the A objects, the markedForDelete.contains(obj)
statement
returns true when trying to delete the second B object. They are trully equals, but have different primary keys...
Could this list use Identity instead of objects ?
Regards, Guillaume
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Larry V. Streepy, Jr. Senior Vice President and CTO Health Language, Inc.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
