Hi Bruce,
> Are you using a key-generator? If so, I'm guessing that your
> problem is probably due to the fact that the key generator is
> not run before the object is persisted, hence the object id of zero.
>
> Bruce
> --
> perl -e 'print
> unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
thanks, you are right: the zero-problem is solved when resigning
key-generator.
But: Is this the expected behavior of the key-generator? In the
castor-doc's it says "during >create< the value of the identity field is
set to the value obtained from the key generator". So if I call
"create(B)" before "create(A)" (in A.jdoBeforeCreate) the sequence value
must have already been fetched.
I see two possible reasons for the problem:
1. Since the foreign-key-constraint is still violated I suppose that
"jdoBeforeCreate()" is actually called after calling create() on the 'A'
object. (This version is actually backed by the output of the logger
(create(A) appears before create(B))).
2. The behavior of the key-generator is not corresponding to the
documentation (above). (But this would not explain the
foreign-key-constraint-problem.)
So in any case - at least any I can see right now - there must be an
error.
Assuming that the error is the wrong order of calling
"jdoBeforeCreate()" in castor one workaround I can see for this problem
is:
* drop foreign-key-constraint,
* resign key-generation for depending entity (B in example above) and
* fetch the sequence value for depending entity manually and set it
before calling create(B).
The trouble I have with this workaround is that I forgo using database
integrity mechanisms, so I will probably end up working arround
persistence framework by directly calling create(B), A.setB(B),
create(A).
What do you think?
Enrico
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
