Hi Martin,
> If I get an A object (always through ODMG) from the DB, change the field > A.b_id to another valid B id and try to persist, this fails.... or > worse, it does not have any effect. Am i forced to get the B object and > perform an A.set(B) or is there any better way to do this knowing the > id? (I am trying to avoid querying B again)
The referenced object B is dominating the FK field b_id in A. This mean if A has no B reference OJB assume that the reference was deleted and set b_id to null. If you lookup A and B was materialized too (auto-retrieve is true in reference-descriptor in A) and then change b_id, OJB get the referenced B and override the changed b_id with the old value.
So you have to load the new B object and replace the referenced object in A.
regards, Armin
Martin I. Levi wrote:
Hi Armin,
Well I figured out what happens. In the rc5 application (which was made some time ago) the repository-settings were:
auto-update=false auto-delete=false auto-retrieve=true
(just like in the rc7 application) but the big difference is that in the r5 application when i changed a 1:1 reference my program cared to look for the new referenced object and load it "inside" the main object and then call ODMG to persist the updated object. This task was not done automatically. What i wonder is if this could be done automatically. I don't know if i am clear enough... I will try an example.
Lets suppose I have an A class and a B class:
class A { Integer id; Integer b_id; B b; //more fields //getters and setters for id, b_id, b and other fields }
class B { Integer id; //more fields //getters and setters for id and other fields }
In sql terms: A and B are mapped to different tables. In the table associated to A one column (mapped to b_id) is a FK to the table associated to B. And id is the mapping of the PK of each table.
If I get an A object (always through ODMG) from the DB, change the field A.b_id to another valid B id and try to persist, this fails.... or worse, it does not have any effect. Am i forced to get the B object and perform an A.set(B) or is there any better way to do this knowing the id? (I am trying to avoid querying B again)
On Mon, 2004-10-04 at 17:13, Armin Waibel wrote:
Hi Martin,
Martin I. Levi wrote:
Well, I have an application on rc5 where everything works well and another application on rc7 which is giving me problems. When I update (through ODMG) an object with 1:1 references, the changes on these are not updated. Im comparing both applications to find out what happens but I still dont know.
difficult to guess what's going wrong. Fixed some spots in ODMG implementation which could be responsible for this behavior.
Please try the latest from CVS OJB_1_0_RELEASE branch (next maintenance release is coming soon)
or see
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=8991
to fix your version manually.
If this doesn't solve your problem, please try to write a test case or modify an existing one to show the issue.
regards, Armin
On Wed, 2004-09-29 at 15:20, Robert r. Sanders wrote:
As I understand it both the OTM and ODMG implementations do this internally, so you must turn it off at the persistance-broker level. I have tried OTM (I don't particularly care for the ODMG API) but as I want to use the Spring framework I decided to stick w/ the PersistanceBroker for now.
Martin I. Levi wrote:
Hi Armin,
I see in the documentation that I cannot use auto-update=true with ODMG.
Is there any way to get OJB working this way:
auto-retrieve=true auto-update=true auto-delete=false
through OTM ? suggestions are welcome!
On Mon, 2004-09-27 at 18:24, Armin Waibel wrote:
Hi Martin,
about repository.dtd http://db.apache.org/ojb/docu/guides/repository.html
the auto-xxx settings http://db.apache.org/ojb/docu/guides/basic-technique.html#Setting+Load%2C+Update%2C+and+Delete+Cascading
and as sub-section in 1:1, 1:n .... section, e.g. http://db.apache.org/ojb/docu/guides/basic-technique.html#1%3A1+auto-xxx+setting
regards, Armin
--------------------------------------------------------------------- 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]
