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: Dirty Take 2 (checked in) (feedback please!)
Date Wed, 11 Aug 2004 22:07:57 GMT
I think this test fails because the auto-update flag is not set to 
'true' or 'object' and OJB use 'false' as default and 'false' was mapped 
to 'link', thus the FK was set in Person but the Address was not stored.

Armin

Brian McCallister wrote:

> Speaking to that -- binding for lazy insertion should be to the 
> transaction, not the connection, though inserting dependencies for eager 
> insertion seems reasonable.
> 
> What are your thoughts on how it should behave?
> 
> -Brian
> 
> On Aug 11, 2004, at 5:52 PM, Brian McCallister wrote:
> 
>> pb.store(..) will execute immediately, which doesn't allow for 
>> re-ordering.
>>
>> It would be possible to do it all lazily, but would then need to 
>> intercept calls to store(..) and delete(..). The re-ordering, right 
>> now, only works on lazy insertions, such as ODMG uses (tx.lock(..)).
>>
>> -Brian
>>
>> On Aug 11, 2004, at 4:41 PM, Jakob Braeuchi wrote:
>>
>>> hi brian,
>>>
>>> i'm playing a little bit with the DirtyBrokerTest.
>>> i added a method to insert a new person and it's new mainAddress:
>>>
>>>         broker.beginTransaction();
>>>         Person person = new Person();
>>>         person.setFirstname("Brian");
>>>
>>>         Address mainAddress = new Address("USA", "Wilmington-Main", 
>>> "Wombat Court");
>>>         person.setMainAddress(mainAddress);
>>>
>>>         broker.store(person);
>>>         broker.commitTransaction();
>>>
>>> this test fails with an integrity constraint violation because the 
>>> person is inserterted before the mainAddress.
>>>
>>> (core.PersistenceBrokerImpl          776 ) Cascade store for this 
>>> reference-descriptor (mainAddress) was set to false.
>>> 1092256841968|0|0|statement|INSERT INTO OTM_PERSON 
>>> (ID,FIRSTNAME,LASTNAME,MAIN_ADDRESS_ID) VALUES (?,?,?,?) |INSERT INTO 
>>> OTM_PERSON (ID,FIRSTNAME,LASTNAME,MAIN_ADDRESS_ID) VALUES 
>>> ('166','Brian','','164')
>>>
>>>
>>> jakob
>>>
>>> Brian McCallister schrieb:
>>>
>>>> Okay, just did a checkin of take 2 on the dirty broker stuff. This 
>>>> is quite different from the previous (which I will delete from CVS 
>>>> as soon as it is no longer useful as a reference to me =)
>>>> -- 
>>>> Basic design is based heavily on ideas in the OTM, but hopefully 
>>>> benefiting from being the second implementation =) It uses a 
>>>> connection + transaction model like the OTM, except that the 
>>>> Connection part is simply a normal PersistenceBroker, and the 
>>>> Transaction isn't (yet?) exposed to the client, but is controlled 
>>>> solely though the pb.[begin|abort|commit]Transaction() methods.
>>>> Internally the DirtyBrokerFactory (which is designed to be 
>>>> instantiated and ioc/bean configured, rather than statically 
>>>> accessed, even though it uses the PBFactory statics to instantiate 
>>>> its brokers) uses a series of listeners on the PB and on the 
>>>> grafolia Unit to handle events between objects and OJB. The grafolia 
>>>> unit (if we want to expose it to client) can also be used in this 
>>>> regard to do true optimistic transactions (though a little bit more 
>>>> plumbing to make it client friendly will be needed here -- basically 
>>>> hooking in the ODMG optimistic column stuff).
>>>> On commit the grafolia unit walks the graph and applies its 
>>>> reachability function (not yet pluggable in grafolia, but soon =) -- 
>>>>  will be in order to properly support proxies) to find newly 
>>>> inserted instances and build a reference analysis of the graph. It 
>>>> then makes the changes and analysis available to OJB, which can 
>>>> order the changes based on looking at the analysis (turns changes 
>>>> into a directed graph based on FK relationships and then sorts them 
>>>> based on the dag traversal).
>>>> -- 
>>>> The org.apache.ojb.dirty.DirtyBrokerTest class in src/test/ shows 
>>>> usages of the stuff. Short form is that it supports, right now: 
>>>> correct dirty-tracking on any PB configuration of auto-*, 
>>>> persistence-by-reachability, statement re-ordering for updates and 
>>>> lazy (reachability based) inserts, and has the hooks necessary (just 
>>>> no API exposed on the PB for it, so nothing to expose the 
>>>> functionality yet) for detach/attach.
>>>> It has some definate rough spots. The statement re-ordering 
>>>> algorithm has the right idea buried in it, but the current impl is 
>>>> definately in the "make it work" phase, not the work right, or work 
>>>> fast. using broker.store(..) on an open transaction can confuse it 
>>>> (not a rough one to fix, just haven't yet).
>>>> A dependency to commons-grafolia (a db-commons-sandbox project, with 
>>>> one author, me) has been added as the graph stuff wasn't dependent 
>>>> on OJB, so I split it off.
>>>> A dependency has been added (temporarily) to commons-graph (a 
>>>> jakarta-commons-sandbox project) to do the topological sort for 
>>>> statement re-ordering. I want to re-implement that part more cleanly.
>>>> Additional Work To Be Done in OJB:
>>>>     Create a grafolia IdentityFactory which wraps OJb id factory
>>>>     Generally clean up the adaptation layer, it is the smelliest 
>>>> hunk of code at the moment.
>>>>     Decide how to expose direct lazy-insert and lazy-delete 
>>>> (executed at commit time)
>>>>         then implement
>>>>     Decide how to expose optimistic transactions
>>>>         then implement
>>>>     Decide how to expose attach/detach
>>>>         then implement
>>>> Additional Work To Be Done In Grafolia
>>>>     Support for arrays like collections (should be a trivial 
>>>> addition to ManagedTrackerFactory)
>>>>     Make GraphAnalysis more useful -- OJB does a lot of munging 
>>>> right now        consider adding client ability to define the visitor
>>>>     Optimize flushing algorithm for unmanaged or mixed 
>>>> managed/instrumented graphs
>>>>     Make the reachability algorithm used by the Graph/Visitor combo 
>>>> a component
>>>>     Refactor/Combine duplicated visitor functionality in 
>>>> Graph/Visitor stuff
>>>> The OJB code has been checked in to OJB CVS in the 
>>>> org.apache.ojb.dirty namespace and is moderately unit tested, with 
>>>> good sample code in the existing unit tests.
>>>> The Grafolia stuff is in db-commons-sandbox/grafolia at 
>>>> http://db.apache.org/commons/sandbox/grafolia/ and has no released 
>>>> binaries (is maven build and has no dependencies so should be 
>>>> straightforwad to use in an IDE or on command line). It is pretty 
>>>> thoroughly unit tested (clover says 81% with the untested mostly 
>>>> being the "you cannot commit a closed transaction" type exceptions). 
>>>> The DefaulUnitTest testcase is probably the best starting point for 
>>>> that library.
>>>> Feedback, please!
>>>> Thanks,
>>>> 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


Mime
View raw message