db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: 1.0.2?
Date Sat, 06 Nov 2004 15:13:43 GMT
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.

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


Mime
View raw message