Matt, Transfer.cascadeSave() just traverses the "object graph" (i.e. top- level object and any composites it contains) and saves any unpersisted, dirty children it finds (like any decent human would do) and then saves the top-level object to boot. It will create any new records or update existing ones and has nothing to do with the actual relationships between the objects other than the fact that the objects exist. It couldn't care less how the objects were created, just that they're present and they're dirty/unpersisted and valid TransferObjects.
I would question using the m2o here too... if the one record really is a parent to these other 2 objects why aren't you using an o2m to the children from the parent? o2m creates accessors on the children to allow access back to the parent... but m2m and m2o don't create that sort of bidi relationship at all, so in almost all cases where I can I use o2m because it creates a much more convenient model. J On Dec 5, 2008, at 4:45 PM, Mark Mandel wrote: > > On Sat, Dec 6, 2008 at 3:25 AM, Matt Williams <[EMAIL PROTECTED]> > wrote: >> >> >> But if I want to do a cascadeCreate() that writes a new record to all >> of these tables at once, it seems I have to reverse that relationship >> and do a onetoomany from the parent to the children. > > What makes you think that? > > cascade* oeprations don't favour any relationships. > > Mark --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
