This one time, at band camp, Lucas Cofresi said:
> Inserting/updating complex objects (i.e., objects
> which contains, or relates to, other objects) begs for
> autostore to be set. The alternative (no autostore)
> requires the developer to traverse the object graph
> and handle the dependant/related inserts/updates
> manually (which IMHO fully defeats the purpose of
> using Castor altogether).
> Castor implementation of inserts/updates with
> autostore is inadequate, to say the least. When
> inserting objects containing other first-class objects
> (usually, mapped as foreign keys), Castor blindly
> attemps to insert all contained objects, without
> regard for the fact that in most cases, these objects
> already exist, raising duplicate identity exceptions
> which cause the transaction to roll back.
> The same problem may occur in inserts when the object
> has one-to-many or many-to-many relationships mapped.
> Likewise, updating objects to which new children have
> been added may suffer from the same predicament.
> Going through the mailing archive for the past twelve
> months I have found several similar complaints, none
> of which seemed to have been properly addressed.
> Is there a way around? Has this problem been
> officially acknowledged, added to a to-do list,
> schedule for consideration?
Lucas,
Is it possible for you to provide a test case for this situation so that we
can reproduce it and file a bug on it?
Bruce
--
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
