db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.Braeuchi" <jbraeu...@gmx.ch>
Subject Re: [VOTE] Release OJB 1.0.1
Date Sat, 31 Jul 2004 12:02:16 GMT
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.

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


Mime
View raw message