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 23:15:32 GMT
Went to expose, but all my tests are failing with sequence manager  
problems =/

Need to figure out what is different (other than everything ;-)

-Brian

On Aug 11, 2004, at 6:22 PM, Brian McCallister wrote:

> Will add a mechanism for getting ahold of the unit in a few minutes...  
> won't be a permanent solution, but will allow testing, etc.
>
> -Brian
>
> On Aug 11, 2004, at 6:16 PM, Brian McCallister wrote:
>
>> 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
>>
>>
>
>
>
> ---------------------------------------------------------------------
> 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