db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <mccallis...@forthillcompany.com>
Subject Re: Dirty Take 2 (checked in) (feedback please!)
Date Wed, 11 Aug 2004 22:16:21 GMT
yes, though for persistence-by-reachability according to JDO, this  
would need to be inserted if person were inserted.

auto-update here is an option, but for a lazy insertion (get the  
grafolia unit associated with the pb transaction and use  
Unit#insert(..)), the callbacks would evaluate the ordering at insert  
time for this.

-Brian

On Aug 11, 2004, at 6:07 PM, Armin Waibel wrote:

> 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
>
>



---------------------------------------------------------------------
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