Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <F95A0C12-EBE4-11D8-9B93-000A95782782@forthillcompany.com>
References: <6366AEDE-EA61-11D8-B6FA-000A95782782@forthillcompany.com>
 <411A8488.8050003@gmx.ch>
 <B075CCF0-EBE0-11D8-9B93-000A95782782@forthillcompany.com>
 <DDD85ECF-EBE0-11D8-9B93-000A95782782@forthillcompany.com>
 <411A98BD.3040308@apache.org>
 <1382120B-EBE4-11D8-9B93-000A95782782@forthillcompany.com>
 <F95A0C12-EBE4-11D8-9B93-000A95782782@forthillcompany.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <57C9CDFC-EBEC-11D8-9B93-000A95782782@forthillcompany.com>
Content-Transfer-Encoding: 7bit
From: Brian McCallister <mccallister@forthillcompany.com>
Subject: Re: Dirty Take 2 (checked in) (feedback please!)
Date: Wed, 11 Aug 2004 19:15:32 -0400
To: "OJB Developers List" <ojb-dev@db.apache.org>

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