Hi Bob,

Robert J Celestino wrote:
Hello All,

Trying to get my own example running using ODMG and I feel like I am
missing something very basic.

My simple class has 2 simple string attributes (field descriptors),
one referenced attribute (reference descriptor), and one collection
(collection descriptor)

Here is what happens:

1 - Insert, retrieve, and cascading delete work correctly. 2 - I read
from the DB, change a string attribute and store. The DB is NOT
updated. 3 - I read from the DB, change the reference attribute and
store. The DB is NOT updated. 4 - I read from the DB, add an element
to the collection and store. The DB *IS* updated! 5 - I read from the
DB, delete an element from the collection and store. The DB is NOT
updated.


All these scenarios are covered by tons of junit testcases. So I'm pretty sure OJB is able to deal with them correctly.


It does not throw any exceptions, it just does not seem to do what I
expect. Which is basically to update an existing object.

Now, all of the above scenarios work correctly using the PB. I am
currently using the PB for all of my "real" work and it works
perfectly. But just for my own curiosity, and interest, what could I
be going wrong here?

I did make the changes to the repository_user.xml as suggested.

Note that the changes to the objects that I describe are not
happening within the transaction lock as shown in the tutorial.

If you modify Objects a transaction the ODMG tx manager is not able to detect the changes and won't generate any SQL statements.


If you want to transfer modified Ojbects into a ODMG transaction you have to use a special trick, as this is simply not covered by the ODMG programming model. (it's not OJB specific).

Object dirtyInstance = ...

((TransactionImpl) tx).markdirty(dirtyInstance);

This will tell the tx manager that your instance must be persisted at transaction commit.

cu,
Thomas

For
the sake of completeness, I did try that as well with the same
results. Although I do not know how I would that in a real
application.

Thanks again! Bob c

---------------------------------------------------------------- Bob
Celestino SAS Research and Development 919 - 531 - 9425 [EMAIL PROTECTED]


SAS - The Power to Know

---------------------------------------------------------------------
 To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to