I'm willing to go with this for now because the "manual" approach is
fairly short and straightforward. While what I proposed may (or may not)
be more architecturally sound, it would certainly be more complicated.
I'd still keep that part of code in mind as a candidate refactoring as you
work through other issues that may have similar needs.
-- KevinOn Mon, 30 Jun 2008 01:54:07 -0400, Andrey Razumovsky <razumovsky.andre..mail.com> wrote:
> The first and obvious reason was to use 'common' callbacks - like > EntityListener and DataMapListener. But that would really make life > harder > because I need not change the rule every time. For instance, I probably > don't wan't to mess with it when I will code copy-paste. Finally, as > long as > I remember, 'add' events are not fired sometimes (for instance, when > syncronizing Db and Obj entities. > Other rule for me was not to break into main core. Def rules are likely > modeler's property and jdk-1.5-unpublished need not know about them. So I > ended in manually checking all the places where a new relationship is > created. > To answer directly to your question, now I see that EntityMergeListener > can > work in DbLoader if we add the same API to work with EntityMergeListeners > and then pass them to EntityMergeSupport. Still, there's DbLoaderHelper. > I > need to save entities to an array first because it comes to the helper > without any relationships yet synchronized. > > 2008/6/30, Kevin Menard (JIRA) <de..ayenne.apache.org>: >> >> >> [ >> https://issues.apache.org/cayenne/browse/CAY-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986#action_12986] >> >> Kevin Menard commented on CAY-436: >> ---------------------------------- >> >> All in all, this looks pretty good. A couple questions: >> >> 1) In DbLoaderHelper, is there any reason that you need to explicitly >> update the ObjEntity? Or rather, is there a reason that your observer >> pattern fails to work here? >> >> 2) Is there a reason that the observer pattern fails in >> ObjRelationshipInfoModel#savePath? >> >> I may be looking at the code wrong, but it strikes me that the >> EntityMergeListener or something similar could be used in such a way >> that >> you don't actually have to hook in explicit updates in so many places. >> >> > In modeler, change default object relationship delete rule >> > ---------------------------------------------------------- >> > >> > Key: CAY-436 >> > URL: https://issues.apache.org/cayenne/browse/CAY-436 >> > Project: Cayenne >> > Issue Type: Improvement >> > Components: Cayenne Core Library, CayenneModeler GUI >> > Environment: winxp, M7 >> > Reporter: weidox >> > Assignee: Kevin Menard >> > Fix For: UNDEFINED FUTURE >> > >> > Attachments: patch-CAY-436.txt >> > >> > >> > Should be good to change default delete rules for object >> relationships, >> one to many - cascade, and vice versa - to nullify. I think it's the >> rules >> used mostly for these relationships. >> > And the best thing would be to have configurable options for these, >> but >> that's more complex. >> >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> >>
This archive was generated by hypermail 2.0.0 : Tue Jul 01 2008 - 20:09:09 EDT