db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: Multiple Extents Issue (Was RE: [VOTE] Release OJB 1.0.1)
Date Sat, 07 Aug 2004 12:56:43 GMT
hi charles,

this means that the copy of the query is wrong.
i'll check this asap.

jakob


Charles Anthony schrieb:

> I think I've found the underlying problem; when copying a QueryByCritera, we
> don't copy the criteria itself... So, in
> BrokerHelper.setConcreteClassCriteria, when we add the IN criteria to the
> copyQuery we are also adding to the aQuery parameter.
> 
> 
> 
>>-----Original Message-----
>>From: Charles Anthony 
>>Sent: 07 August 2004 12:55
>>To: Charles Anthony; 'OJB Developers List'
>>Subject: Multiple Extents Issue (Was RE: [VOTE] Release OJB 1.0.1)
>>
>>
>>Hi All, 
>>
>>I've managed to modify the MultipleTableExtentAwareQueryTest 
>>testcase to reproduce this error. Which is handy. 
>>
>>I shall email my test case modifcations to Armin, Brian & 
>>Jakob. Essentially, as soon as you have mutltiple table 
>>extents, and you use an ojbConcreteClass attribute to specify 
>>the appropriate class to materialize, queries go horribly wrong.
>>
>>At least I've created a test case this weekend, if not a solution...
>>
>>(Oh, and  PersistenceBrokerImpl.getRsIteratorFromQuery  
>>doesn't recurse like I implied yesterday. Doh - it'd been a  
>>long day.)
>>
>>Cheers,
>>
>>Charles.
>>
>>
>>>-----Original Message-----
>>>From: Charles Anthony 
>>>Sent: 06 August 2004 17:54
>>>To: Charles Anthony; 'OJB Developers List'
>>>Subject: RE: [VOTE] Release OJB 1.0.1
>>>
>>>
>>>Actually, just in case anyone is curious, here's a sort of 
>>>redux of the problem.
>>>We have a hierarchical situtation a bit like this
>>>
>>>             A
>>>         B     C
>>>      D    E     F  G
>>>
>>>i.e. B and C are subclasses of A, 
>>>D and E are subclasses of B
>>>F and G are subclasses of C
>>>
>>>A, B and C are mapped to tables TABLE_A, TABLE_B and TABLE_C
>>>
>>>(Our hierarchy is much deeper and wider)
>>>
>>>If we query for all A's (and subclasses), the actual queries 
>>>we get are something like
>>>select * from TABLE_A where OJBCONCRETECLASS in ('A')
>>>select * from TABLE_B where OJBCONCRETECLASS in ('A') AND 
>>>OJBCONCRETECLASS in ('B', 'D', 'E') 
>>>select * from TABLE_C where OJBCONCRETECLASS in ('A') AND 
>>>OJBCONCRETECLASS in ('C', 'F', 'G') 
>>>
>>>So we never find any anthing from tables B or C.
>>>
>>>I think we should be getting
>>>
>>>select * from TABLE_A where OJBCONCRETECLASS in ('A')
>>>select * from TABLE_B where OJBCONCRETECLASS in ('B', 'D', 'E') 
>>>select * from TABLE_C where OJBCONCRETECLASS in ('C', 'F', 'G') 
>>>
>>>I think it's something to do with the recursion in 
>>>PersistenceBrokerImpl.getRsIteratorFromQuery - and maybe the 
>>>Query.withExtents flag.
>>>
>>>But I could be wrong.
>>>
>>>If anyone can think of anything, please let me know (it is 
>>>really rather urgent).
>>>
>>>Cheers,
>>>
>>>Charles.
>>>
>>>
>>>>-----Original Message-----
>>>>From: Charles Anthony 
>>>>Sent: 06 August 2004 17:35
>>>>To: 'OJB Developers List'
>>>>Subject: RE: [VOTE] Release OJB 1.0.1
>>>>
>>>>
>>>>
>>>>
>>>>I think I've got a nasty issue with extents with the current 
>>>>cvs version - but I don't think I'll be able to isolate it 
>>>>any time soon. As soon as I think I know what it is, I'll let 
>>>>you know - but please don't wait on me (ha! as if).
>>>>
>>>>Cheers,
>>>>
>>>>Charles
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Brian McCallister [mailto:mccallister@forthillcompany.com]
>>>>>Sent: 06 August 2004 17:22
>>>>>To: OJB Developers List
>>>>>Subject: Re: [VOTE] Release OJB 1.0.1
>>>>>
>>>>>
>>>>>
>>>>>On Aug 6, 2004, at 11:29 AM, Armin Waibel wrote:
>>>>>
>>>>>
>>>>>>Code freeze at Sunday night (GTM), then one or two days 
>>>>
>>>>to run the  
>>>>
>>>>>>unit-tests against all popular databases, check 
>>>
>>>performance tests.
>>>
>>>>>>--> Release end of next week?
>>>>>
>>>>>
>>>>>Perfect!
>>>>>
>>>>>-Brian
>>>>>
>>>>>
>>>>>>Armin
>>>>>>
>>>>>>
>>>>>>
>>>>>>>-Brian
>>>>>>>On Aug 2, 2004, at 4:00 PM, Jakob Braeuchi wrote:
>>>>>>>
>>>>>>>>hi all,
>>>>>>>>
>>>>>>>>J.Braeuchi schrieb:
>>>>>>>>
>>>>>>>>
>>>>>>>>>hi robert,
>>>>>>>>>Robert S. Sfeir schrieb:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Hum... I've just been catching up to this, I hope
I'm 
>>>>>
>>>>>not stepping  
>>>>>
>>>>>>>>>> in too
>>>>>>>>>>late, or out of line and didn't get the issue...
>>>>>>>>>>
>>>>>>>>>>If you were doing this with standard SQL approach
and 
>>>>>
>>>>>your DB had   
>>>>>
>>>>>>>>>>foreign
>>>>>>>>>>keys, you'd never be able to store your main object

>>>>>
>>>>>without the   
>>>>>
>>>>>>>>>>referenced
>>>>>>>>>>keys already existing.  I think this should be 
>>>
>>>considered a  
>>>
>>>>>>>>>>feature,  and
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>that's why i'd like to have referential integrity 
>>>>>
>>>>>enabled in our   
>>>>>
>>>>>>>>>test-dbs.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>probably good form to force the user to think about

>>>>>
>>>>>what they're   
>>>>>
>>>>>>>>>>persisting
>>>>>>>>>>and how they're doing it.  If it's documented, then

>>>>
>>>>users will  
>>>>
>>>>>>>>>>adapt  to it.
>>>>>>>>>>I think that trying to make everything transparent
to 
>>>>>
>>>>>the user is   
>>>>>
>>>>>>>>>>always a
>>>>>>>>>>great goal, but let's not treat them like dummies
;-)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>we'll have to document it, because we do not have 
>>>
>>>statement   
>>>
>>>>>>>>>reordering.
>>>>>>>>
>>>>>>>>
>>>>>>>>sorry for this misinformation. we *have* reordering, 
>>>>>
>>>>>although not   
>>>>>
>>>>>>>>always perfect ;)
>>>>>>>>
>>>>>>>>jakob
>>>>>>>>
>>>>>>>>
>>>>>>>>>jakob
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Just my 2 cents.
>>>>>>>>>>
>>>>>>>>>>R
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>On 7/31/04 7:38 AM, "Jakob Braeuchi" 
>>>
>>><jbraeuchi@gmx.ch> wrote:
>>>
>>>>>>>>>>
>>>>>>>>>>>hi armin,
>>>>>>>>>>>
>>>>>>>>>>>Armin Waibel schrieb:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>Hi,
>>>>>>>>>>>>
>>>>>>>>>>>>Jakob Braeuchi wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>hi armin,
>>>>>>>>>>>>>
>>>>>>>>>>>>>storing the single-refs *before* storing
the mainObj 
>>>>>
>>>>>solves the  
>>>>>
>>>>>>>>>>>>> problem:
>>>>>>>>>>>>>
>>>>>>>>>>>>>       Transaction tx = odmg.newTransaction();
>>>>>>>>>>>>>       tx.begin();
>>>>>>>>>>>>>       db.makePersistent(s_ref_1);
>>>>>>>>>>>>>       db.makePersistent(s_ref_2);
>>>>>>>>>>>>>       db.makePersistent(s_ref_3);
>>>>>>>>>>>>>       db.makePersistent(s_ref_4);
>>>>>>>>>>>>>
>>>>>>>>>>>>>       db.makePersistent(obj_1);
>>>>>>>>>>>>>       db.makePersistent(obj_2);
>>>>>>>>>>>>>       tx.commit();
>>>>>>>>>>>>>
>>>>>>>>>>>>>so what's wrong with this ? is the odmg-api
supposed 
>>>>>
>>>>>to be able  
>>>>>
>>>>>>>>>>>>>to
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>solve this problem without a little help from
the user ?
>>>>>>>>>>>>    Indeed it should always be possible to
store an 
>>>>>
>>>>>object with   
>>>>>
>>>>>>>>>>>>references
>>>>>>>>>>>>without persist each reference before the
main 
>>>>>
>>>>>object. If you   
>>>>>
>>>>>>>>>>>>don't use
>>>>>>>>>>>>Identity columns it is possible (think we
have 
>>>>>
>>>>>odmg-tests doing   
>>>>>
>>>>>>>>>>>>this).
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>well i'm not sure about this. i'd expect that
the fks 
>>>>>
>>>>>are set   
>>>>>
>>>>>>>>>>>properly, but i
>>>>>>>>>>>doubt that it works with referential integrity
enabled :(
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>If we can't fix the problem we should note
your 
>>>>
>>>>workaround in
>>>>
>>>>>>>>>>>>release-notes file.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>that's the only solution i have.
>>>>>>>>>>>
>>>>>>>>>>>jakob
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>The problem (as you mentioned) is the early
FK 
>>>>
>>>>binding in odmg
>>>>
>>>>>>>>>>>>implementation. On commit the objects should
be 
>>>>>
>>>>>reordered and  
>>>>>
>>>>>>>>>>>>then  after
>>>>>>>>>>>>the insert of the 1:1 reference the FK should
be set 
>>>>>
>>>>>in main   
>>>>>
>>>>>>>>>>>>object.
>>>>>>>>>>>>Same way PB-api works.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>we have a mainObject with a 1:1 relationship
to a   
>>>>>>>>>>>>>>SingleReference.
>>>>>>>>>>>>>>during tx.commit the mainObj is save
first, 
>>>>>
>>>>>storeReferences  
>>>>>
>>>>>>>>>>>>>>does  NOT
>>>>>>>>>>>>>>save this singleRef because of auto-settings

>>>
>>>set to false.
>>>
>>>>>>>>>>>>[off-topic]
>>>>>>>>>>>>This is a more general problem of current
odmg/otm 
>>>>>
>>>>>design, they   
>>>>>
>>>>>>>>>>>>can't
>>>>>>>>>>>>use the auto-xxx features of the PB-api. For
odmg 
>>>>>
>>>>>(and otm as  
>>>>>
>>>>>>>>>>>>far  as I
>>>>>>>>>>>>know) all reference auto-update/delete settings

>>>>
>>>>have to be   
>>>>
>>>>>>>>>>>>'false'. It's
>>>>>>>>>>>>a shame, because PB-api can handle all kinds
of  
>>>>>>>>>>>>reference/linking  in a
>>>>>>>>>>>>correct way.
>>>>>>>>>>>>But current top-level implementations rebuild
this 
>>>>>
>>>>>functionality  
>>>>>
>>>>>>>>>>>> instead
>>>>>>>>>>>>of using the PB-api resources. So the PB-api
lacks of   
>>>>>>>>>>>>functionality and
>>>>>>>>>>>>extendable design or the top-level implementations

>>>>>
>>>>>"use wrong   
>>>>>
>>>>>>>>>>>>design".
>>>>>>>>>>>>Think we should discuss this.
>>>>>>>>>>>>
>>>>>>>>>>>>Some time ago I think about a callback/listener

>>>>>
>>>>>method in the   
>>>>>
>>>>>>>>>>>>internal
>>>>>>>>>>>>PB-api (in 1.1 we will extend PB interface
to deal 
>>>>>
>>>>>with internal
>>>>>
>>>>>>>>>>>>functionality - for the present this new 
>>
>>interface called
>>
>>>>>>>>>>>>PersistenceBrokerExt and extend PersistenceBroker).
>>>>>>>>>>>>Maybe a special action listener. E.g. the
transaction 
>>>>>
>>>>>class of  
>>>>>
>>>>>>>>>>>>the
>>>>>>>>>>>>top-level api (TL-api) implements this listener
and 
>>>>>
>>>>>on commit  
>>>>>
>>>>>>>>>>>>the  TL-api
>>>>>>>>>>>>pass the first persistent object to the PB-api

>>>>>
>>>>>(store/delete).  
>>>>>
>>>>>>>>>>>>But
>>>>>>>>>>>>before perform the delete/store call the PB-api

>>>>
>>>>notify the   
>>>>
>>>>>>>>>>>>listener. If
>>>>>>>>>>>>the listener allows the operation the PB store/delete

>>>>>
>>>>>call will  
>>>>>
>>>>>>>>>>>>be  done
>>>>>>>>>>>>and if the persistent object has references
the 
>>>>>
>>>>>PB-api handle  
>>>>>
>>>>>>>>>>>>these
>>>>>>>>>>>>referenced objects dependent on the auto-xxx

>>>>>
>>>>>settings. But for  
>>>>>
>>>>>>>>>>>>each
>>>>>>>>>>>>referenced object store/delete call the listener
will 
>>>>>
>>>>>be asked   
>>>>>
>>>>>>>>>>>>again. If
>>>>>>>>>>>>the listener dislike the operation the PB-api
doesn't  
>>>>>>>>>>>>store/delete  and
>>>>>>>>>>>>the cascade operation leave out this object.
>>>>>>>>>>>>This way the TL-api can decide (dirty check,
locking 
>>>>>
>>>>>check, ...)  
>>>>>
>>>>>>>>>>>> which
>>>>>>>>>>>>persistent object should be stored/deleted
without 
>>>>>
>>>>>dealing with  
>>>>>
>>>>>>>>>>>>FK
>>>>>>>>>>>>settings/linking/references.
>>>>>>>>>>>>
>>>>>>>>>>>>Alternative will be to move all TL-api services
like   
>>>>>>>>>>>>dirty-detection,
>>>>>>>>>>>>locking, ... to the kernel, then the TL-api
can 
>>>
>>>use these   
>>>
>>>>>>>>>>>>services. This
>>>>>>>>>>>>means that OTM and kernel will be merged in
some way.
>>>>>>>>>>>>
>>>>>>>>>>>>regards,
>>>>>>>>>>>>Armin
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>jakob
>>>>>>>>>>>>>
>>>>>>>>>>>>>Jakob Braeuchi schrieb:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>hi armin,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>i was debugging   
>>>>>>>>>>>>>>NativeIdentifierTest#testReferenceInsertUpdateODMG
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>for quite some time and unfortunately i do
not see a 
>>>>>
>>>>>solution to  
>>>>>
>>>>>>>>>>>> this
>>>>>>>>>>>>problem :(
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>we have a mainObject with a 1:1 relationship
to a   
>>>>>>>>>>>>>>SingleReference.
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>during tx.commit the mainObj is save first,

>>>>>
>>>>>storeReferences does  
>>>>>
>>>>>>>>>>>> NOT
>>>>>>>>>>>>save this singleRef because of auto-settings
set to 
>>>>
>>>>false.   
>>>>
>>>>>>>>>>>>afterStore of
>>>>>>>>>>>>mainObj the db-generated key is put into the
object. 
>>>>>
>>>>>i tried to   
>>>>>
>>>>>>>>>>>>call
>>>>>>>>>>>>setReferenceFKs in afterStore, but this is
useless 
>>>>
>>>>because   
>>>>
>>>>>>>>>>>>singleRef is
>>>>>>>>>>>>not saved and still carries the dummy key
!
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>so, imo we cannot insert the mainObj
referencing a 
>>>>>
>>>>>non existent
>>>>>
>>>>>>>>>>>>singleRef !
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>evene if we could update all the fks
in the mainObj 
>>>>>
>>>>>the row in  
>>>>>
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>database is still wrong, because it contains
to dummy 
>>>>>
>>>>>key of the  
>>>>>
>>>>>>>>>>>> singleRef:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>INSERT INTO NATIVE_MAIN_OBJECT (REF_ID,NAME)
VALUES
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>('-2','testReferenceInsert_main_1091213387781')
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>this actually only works because there
are no 
>>>>
>>>>referential   
>>>>
>>>>>>>>>>>>>>constraints.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>jakob
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Armin Waibel schrieb:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>Jakob Braeuchi wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>hi armin,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>are you solving this issues
for 1.0.1 ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>I will try to do so, but concurrently
I'm working 
>>>>>
>>>>>on the 1.1   
>>>>>
>>>>>>>>>>>>>>>stuff
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>so any help is much appreciated.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>Armin
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>jakob
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>Armin Waibel schrieb:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>Hi all,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>Brian McCallister wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>We have a number of
user-requested bug 
>>
>>fixes in the
>>
>>>>>>>>>>>>OJB_1_0_RELEASE branch at the moment. I'd
like to 
>>>>>
>>>>>push a release.
>>>>>
>>>>>>>>>>>>>>>>>There are some open issues
(2 failing 
>>>
>>>odmg-test cases,
>>>
>>>>>>>>>>>>CollectionTest) and a serious bug in FK assignment

>>>>>
>>>>>when odmg-api  
>>>>>
>>>>>>>>>>>> was
>>>>>>>>>>>>used with native DB Identity columns 
>>>>>
>>>>>(SequenceManagerNativeImpl).
>>>>>
>>>>>>>>>>>>NativeIdentifierTest, on insert of objects
with 1:1 
>>>>>
>>>>>references.   
>>>>>
>>>>>>>>>>>>Problem
>>>>>>>>>>>>occurs in TransactionImpl#lock(Object obj,
int 
>>>>>
>>>>>lockMode) line  
>>>>>
>>>>>>>>>>>>235.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>When using native Identity
columns, OJB use a 
>>>>
>>>>temporary  
>>>>
>>>>>>>>>>>>>>>>>dummy
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>value for created OJB Identity objects of
new 
>>
>>pc objects  
>>
>>>>>>>>>>>>(negative  long
>>>>>>>>>>>>values are used as dummy values for Identity

>>>>>
>>>>>columns), so the FK
>>>>>
>>>>>>>>>>>>assignment is only valid after store of the

>>>>
>>>>referenced object.
>>>>
>>>>>>>>>>>>>>>>>TransactionImpl#lock assign
the FK before the 
>>>>>
>>>>>referenced   
>>>>>
>>>>>>>>>>>>>>>>>object
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>was written to DB.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>regards,
>>>>>>>>>>>>>>>>>Armin
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>+1/0/-1
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>Vote will end Sunday,
Aug 1.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>-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
>>>>>
>>>>>
>>>>
> 
> 
> ___________________________________________________________
> HPD Software Ltd. - Helping Business Finance Business
> Email terms and conditions: www.hpdsoftware.com/disclaimer 
> 
> 
> 
> ---------------------------------------------------------------------
> 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