db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: 1.0.2?
Date Sat, 06 Nov 2004 15:57:06 GMT
hi armin,

Armin Waibel schrieb:

> Jakob Braeuchi wrote:
> 
>> hi armin,
>>
>> Armin Waibel schrieb:
>>
>>> Hi Jakob,
>>>
>>> Jakob Braeuchi wrote:
>>>
>>>> hi armin,
>>>>
>>>> i have a patched object-envelope that works for deletes and passes 
>>>> all testcases without errors. it's not so elegant because the map 
>>>> includes the whole collection for 1:n relationships. but i can send 
>>>> you the code if you like.
>>>>
>>>
>>> great! If your patch fit all requirements check it in.
>>
>>
>>
>> it does of course not fit all of the requirements on your list ;)
> 
> 
> It's a pity, so we have to work further on ;-)
> I started today working on this stuff too. Maybe we can merge our work 
> to resolve most issues.
> 
> 
>> i only tried to solve the problem when objects are removed from a 
>> collection or array.
>>
> 
> how do you do this?

the map holds the whole collection for 1:n relationships (not only it's size) 
and then i walk the old and the new collection.

> 
> 
>> you're list of problem is quite long ! but i eventually have to add 
>> another one:
>>
> 
> ohh no!
> 
>> when i walked the collections to detect new / deleted objects i found 
>> a strange issue.
>>
>> oldCol is a collection of proxies and newObj is a prox contained in 
>> oldCol:
>>
>>             Object newObj = newIter.next();
>>             if ((oldCol != null) && (!oldCol.contains(newObj)))
>>
>> but contains() returns false ! after some digging i found that 
>> equals() does not work properly for proxies.
>>
>> proxyA.equals(proxyB)
>> in InvocationHandler#invoke proxyA object is converted to the 
>> realSubject so equals is invoked on the realSubject with proxyB as 
>> argument; needless to mention that this will return false.
>>
> 
> To detect deleted objects I use the Identity of the object. If the 
> reference is a proxy (single or collection proxy) I add the image class 
> (e.g. ObjectEnvelope or a helper class like ImageContainer) itself as 
> listener.
> If the collection proxy was materialized all object identities will be 
> traced. This should solve problems with proxy objects.

i think this is a more general problem that not only could happen in 
object-envelope. but i do have a fix for that :)

...

             // BRJ: make sure that the object to be compared is a real object
             // otherwise equals will return false.
             if ("equals".equals(methodName) && args[0] != null)
             {
                 Object otherObj = ProxyHelper.getRealObject(args[0]);
                 args[0] = otherObj;
             }

             subject = getRealSubject();
             return method.invoke(subject, args);
...


i will send you my patched classes to your mail-account.

jakob

> 
> In my patch I try to detect new objects when the commit was prepared. 
> All registered objects will register again all references. So the new 
> objects should be detected.
> 
> Armin
> 
>> jakob
>>
>>
>>
>>>
>>> The problems I found (and try to correct with my patch) for current 
>>> ObjectEnvelope class are:
>>>
>>> - Think when the image is done proxy objects and proxy references 
>>> will be materialized (e.g. reference objects can be proxies itself too)
>>>
>>> - The image map (ObjectEnvelope#getMap(...)) contains all persistent 
>>> object field values and the comparison is done between different 
>>> image maps. But not all field values of persistent objects are 
>>> comparable via equals-methods (ObjectEnvelope#hasChanged(...)).
>>> E.g. complex fields fields like arrays or fields using a 
>>> FieldConversion from an String[] to String. If the user change one 
>>> array entry the change will not be detected (because both maps refer 
>>> to the same array object).
>>> Similar problem for byte[], Date fields, ... think we should generate 
>>> a unique hashCode() for arrays or other unique number representation 
>>> of the field (e.g. Date.getTime()...).
>>>
>>> - How to handle Array, Clob, Blob, Ref, URL, ... fields in the object 
>>> image. How can we detect changes (think it's not possible).
>>>
>>> - How to handle serialized objects (objects pass to client via 
>>> network and serialized version contains changes, in 
>>> TransactionExt#markDirty I fixed this by replacing the object used in 
>>> ObjectEnvelope, so the changes will be detected). We don't have 
>>> detach/attach support.
>>>
>>> - Proxy listener problem? Shouldn't the proxy listener objects be 
>>> removed after object materialization to free the listener objects? A 
>>> object could not be materialized several times, so why keep the 
>>> listener?
>>>
>>> - detection of new and deleted referenced objects in 1:1, 1:n m:n 
>>> references
>>>
>>> - If the user remove an referenced object, e.g. remove an referenced 
>>> object from the collection of a 1:n, m:n reference, the removed 
>>> object should not be deleted, the removed reference should only be 
>>> "unlinked". Only if method Database.deletePersistent(...) was called 
>>> an object should be deleted. This behavior would allow proper 
>>> handling of m:n relations (unlink means remove from indirection table).
>>> Assume in current implementation the behavior isn't consistent, maybe 
>>> I'm wrong.
>>>
>>> Did you found more issues in current ODMG implementation?
>>>
>>> regards,
>>> Armin
>>>
>>>
>>>> jakob
>>>>
>>>> Armin Waibel schrieb:
>>>>
>>>>> Hi Jakob,
>>>>>
>>>>> Jakob Braeuchi wrote:
>>>>>
>>>>>> hi brian, armin,
>>>>>>
>>>>>> what's going on for 1.0.2 ?
>>>>>>
>>>>>
>>>>> Sorry, feel a little drained, so I don't spend much time on OJB.
>>>>> Will try to finish work on weekend, otherwise we should release 
>>>>> 1.0.2 without improved ObjectEnvelope class (and include these 
>>>>> changes in 1.0.3) - release at Sunday?
>>>>>
>>>>> regards,
>>>>> Armin
>>>>>
>>>>>
>>>>>> jakob
>>>>>>
>>>>>> Armin Waibel schrieb:
>>>>>>
>>>>>>> update release notes, modify test case.
>>>>>>>
>>>>>>> But get still two failures when run odmg test cases. Think the

>>>>>>> failures are a result of the changes made in handling of the

>>>>>>> ManageableCollection#.afterStore(...)
>>>>>>> in PBImpl (call only when auto-update 'OBJECT' is set).
>>>>>>>
>>>>>>> To fix this problem we have to improve ObjectEnvelope 
>>>>>>> (encapsulates a persistent object) internal object image to 
>>>>>>> detect new and deleted references. Then the new/deleted 
>>>>>>> references could be handled on odmg level and ODMG-impl no longer

>>>>>>> rely on RemovalAware collections.
>>>>>>>
>>>>>>> Start working on that stuff, but it's not finished yet.
>>>>>>>
>>>>>>> regards,
>>>>>>> Armin
>>>>>>>
>>>>>>> Armin Waibel wrote:
>>>>>>>
>>>>>>>> Hi Brian,
>>>>>>>>
>>>>>>>> Brian McCallister wrote:
>>>>>>>>
>>>>>>>>> Before I left we had a passing vote for 1.0.2 release
>>>>>>>>>
>>>>>>>>
>>>>>>>> Last weeks I couldn't spend much time in OJB development.
>>>>>>>> There are still some failing test cases. I will have a look
at 
>>>>>>>> this tomorrow, modify the test classes to skip failing tests
and 
>>>>>>>> add notes to the release-notes file.
>>>>>>>> Could we put off the deadline one day?
>>>>>>>>
>>>>>>>> Armin
>>>>>>>>
>>>>>>>>
>>>>>>>>> Did anyone ever make it?
>>>>>>>>>
>>>>>>>>> If not, i can tonight.
>>>>>>>>>
>>>>>>>>> -Brian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------

>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>>>>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------

>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>>>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------

>>>>>>>
>>>>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message