RE: [Objectbridge-developers] Order of commit in ODMG transaction

[Charles A. <cha...@hp...>]

Hi Thomas,

I have dropped my constraints for the time-being, in order to get =
things
going.

It would be very useful to have an idea of what is on the to-do list, =
and an
idea of what is in the next release... the task-list at SourceForge =
seems as
though it may be rather out of date..

What would be very useful indeed would be a 'roadmap', showing what =
features
you may be planning for what release. These are, of course, a little
time-consuming and frequently become rapidly out of date.

I must say, though, I am very impressed with the code in the project; =
it's
clarity and simplicity is superb.=20

With thanks,

Charles.

> -----Original Message-----
> From: Mahler Thomas [mailto:tho...@it...]
> Sent: 25 September 2001 13:39
> To: 'Charles Anthony'; =
'obj...@li...'
> Subject: AW: [Objectbridge-developers] Order of commit in ODMG
> transaction
>=20
>=20
> Hi again Charles,
>=20
> > -----Urspr=FCngliche Nachricht-----
> > Von: Charles Anthony [mailto:cha...@hp...]
> > Gesendet: Dienstag, 25. September 2001 11:47
> > An: 'obj...@li...'
> > Betreff: [Objectbridge-developers] Order of commit in ODMG=20
> transaction
> >=20
> >=20
> > Hello,
> >=20
> > I have objects AccountingTransaction and AccountingEntry.=20
> > There is a one to
> > many relationship between the Transaction and Entry. This is=20
> > backed up by a
> > foreign-key constraint in the database.
> >=20
>=20
> Ooops: Proper handling of fk-constraints is definetly not=20
> supported yet :-(
>=20
>=20
> > I want to be able to commit the Transactions and Entries=20
> > within the same
> > (ODMG) transaction (so that either all or none are created in=20
> > the database).
> >=20
> > Unfortunately, it seems that sometimes the AccountEntry gets=20
> > created before
> > the AccountTransaction within the database transaction of the=20
> > commit, thus
> > violating the foreign key constraint.
> >=20
> > After a quick look at the sourcecode, it seems that the=20
> > ObjectStateTable
> > stores the ObjectTransactionWrapper's in a hashtable, and=20
> > that on Commit,
> > the ObjectTransactionWrapper's are processed in hashtable order.
> >=20
> > Whilst I'm not sure this classifies as a bug, it would be an=20
> > immense benefit
> > to have the objects committed in order; it shouldn't be too=20
> > difficult to
> > store the objects order in a Vector (or similar) on the=20
> > ObjectStateTable,
> > and process the Vector on commit.
> >=20
>=20
> I (as a lazy programmer) won't classify it as a bug: it's=20
> merely a feature
> that is not yet implemented yet. We will need a depency graph=20
> to determine
> the right processing order. It should be not too difficult to=20
> generate such
> a graph from the metadata. I'll put it on my my todo list!
>=20
>=20
> > I am sure I'm missing something pretty obvious here; I'm not=20
> > sure what it is
> > though.
> >=20
> > Is there any chance of a solution to this problem ?
> >=20
>=20
> The only thing that will help you right now is to drop the foreign =
key
> constraints in the RDBMS.
> If you are forced to use fk constraints please tell me: I'll put this
> feature to the top of my todo list! But it will take at least=20
> 1 week as I
> want to get out the next release this week.
>=20
> --Thomas
>=20
> > With many thanks,
> >=20
> > Charles.
> >=20
> >=20
> > This email and any attachments are strictly confidential and=20
> > are intended
> > solely for the addressee. If you are not the intended=20
> > recipient you must
> > not disclose, forward, copy or take any action in reliance on=20
> > this message
> > or its attachments. If you have received this email in error=20
> > please notify
> > the sender as soon as possible and delete it from your=20
> > computer systems.
> > Any views or opinions presented are solely those of the=20
> > author and do not
> > necessarily reflect those of HPD Software Limited or its =
affiliates.
> >=20
> >  At present the integrity of email across the internet cannot=20
> > be guaranteed
> > and messages sent via this medium are potentially at risk. =20
> > All liability
> > is excluded to the extent permitted by law for any claims=20
> > arising as a re-
> > sult of the use of this medium to transmit information by or to=20
> > HPD Software Limited or its affiliates.
> >=20
> >=20
> >=20
> > _______________________________________________
> > Objectbridge-developers mailing list
> > Obj...@li...
> > =
https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> >=20
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20


This email and any attachments are strictly confidential and are =
intended
solely for the addressee. If you are not the intended recipient you =
must
not disclose, forward, copy or take any action in reliance on this =
message
or its attachments. If you have received this email in error please =
notify
the sender as soon as possible and delete it from your computer =
systems.
Any views or opinions presented are solely those of the author and do =
not
necessarily reflect those of HPD Software Limited or its affiliates.

 At present the integrity of email across the internet cannot be =
guaranteed
and messages sent via this medium are potentially at risk.  All =
liability
is excluded to the extent permitted by law for any claims arising as a =
re-
sult of the use of this medium to transmit information by or to=20
HPD Software Limited or its affiliates.