Hi,
I have a the following scenario. I have three tables - Key, Value,
Styling. Now a Value belongs to a Key and a Styling. The "primary" table
in this case is Styling (ie, the table where all the action is centred on).
Normally, this would be a "simple" m:n relatioship, however, when I
retrieve the content, I want to include all Key objects, regardless of
whether there is a Value or not. This, obviously, is so I can display
all Keys for the user to edit. Now, I think the solution to this problem
is to set auto-retrieve to "false" and auto-update and auto-delete to
"true" for the Key/Value/Styling relationships and loading the content
separately, and before I load the content back, remove all empty values.
This seems very yucky but workable. That said, there seem to be a lot of
caveats including:
'When using a top-level api (ODMG, OTM, JDO) it is *mandatory to use
specific auto-xxx settings*.
For OTM- and JDO-api the settings are:
- /auto-retrieve="true"/
- /auto-update="false"/
- /auto-retrieve="false"/
This are at the same time the /default/ auto-XXX settings (so don't
specify any of this attributes will have the same effect).
For the ODMG-api the mandatory settings are (since OJB 1.0.2):
- /auto-retrieve="true"/
- /auto-update="none"/
- /auto-retrieve="none"'
And:
/'Be careful when using "opposite" settings, e.g. if you declare a 1:1
reference with auto-retrieve="false" BUT auto-update="object" (or "true"
or "link").
Before you can perform an update on the main object, you have to
"retrieve" the 1:1 reference. Otherwise you will end up with an
nullified reference enty in main object, because OJB doesn't find the
referenced object on update and assume the reference was removed.'
Now, I think, the first one stops me from doing this, though I will be
honest and admit I don't understand what this is trying to say. How do I
know if I am using OTM/ODMG/JDO? I think I am using the PersistentBroker
(I am instantiating a PersistentBroker class) I think the second one
probably doesn't apply to me, but I just want to make sure of that.
Is there a nicer way of doing this scenario?
Thanks.
--
Kamal Bhatt
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
