Re: Delete rules on flattened relationships
On 2011-11-17, at 8:09 PM, David Avendasora wrote: On Nov 18, 2011, at 2:10 AM, Chuck Hill wrote: On 2011-11-16, at 8:24 PM, David Avendasora wrote: On Nov 17, 2011, at 7:48 AM, Paul Hoadley wrote: On 17/11/2011, at 10:08 AM, David Avendasora wrote: On Nov 10, 2011, at 5:34 AM, Paul Hoadley wrote: Say I have two entities, User and Role, and a joining entity UserRole to create a many-to-many relationship between them. So I have a relationship 'userRoles' from User to UserRole (and a relationship 'userRoles' from Role back to UserRole). I flatten the relationship on User, so I also have a 'roles' relationship on that entity. Wait. Also?!? That's insane. That's two distinct relationships representing the same DB information, and one is hiding a huge piece of the action. You are just asking for trouble. User.userRoles is not a class property. All that's exposed is the flattened User.roles. Okay, then that should be alright then, and I think nullify is the proper setting for the non-class real relationships. I don't _think_ I'm talking about anything particularly unusual here, just the standard result of creating a many-to-many relationship with Entity Modeler, with a join entity and Flatten relationships checked. Not unusual, just something that you really shouldn't even be thinking about. That's what flattened relationships do to you. I don't like them. Every time I've tried to use them, I end up regretting it. I find it much better to leave the real relationship and write cover methods that approximate what flattening it would have done. That many-to-many join entity always seems to end up having additional parameters, or be just the right place to put a certain piece of business logic. Then I have to refactor everything that was dependent upon the flattened relationship. I have very rarely had that need to change a to-many relationship. In my experience, they are just an implementation artifact from having to use an RDBMS to store an object graph. Flattening and hiding the join table avoids adding artificial constructs to the Java code. A Good Thing (tm) IMO. Now if the join table is a real object in your system, then by all means don't flatten. Huh. I guess our experiences with many-to-many relationships is just different. Every (seriously, every!) time I've said I'll never need more attributes on, or relationships from or to this many-to-many join entity, I discover some requirement that mandates it. Maybe the difference is that I never think about join entities until I need one in my model to keep the database happy. I just think about object relationships and if it is a simple aggregate, then I use a to-many. If the relationship is ordered or stageful, or whatever, that needs to be modelled in an object and a join table does not enter into it. I have to disagree that because the join table is an implementation artifact that it can be ignored. I am not saying that it can be, I am saying that it should be. :-) I often times thinl that a well conceived model gives the same level of importance to relationships between entities as the entities themselves. But the EOModel is not the true object model. It is a mapping of the true object model to a bastardized, partially relational version. So the relationship that is actually important is the flattened one. The one that references the join table is just noise. How long have these objects been related? Is it an active relationship? What type of relationship is it? Will it stop being active? None of which are about aggregation. There's a lot of meta data surrounding a relationship and a join table is the perfect place to carry it. No. No. No. That is not a join table, that is an intermediate object. They are not the same. One is an artifact of the relational model, the other is a an object in your graph. Maybe that information isn't needed now, but what about later? Do you trust that the next developer isn't going to just add some attributes or additional relationships and leave the compound-PK in place? I don't trust the next dev. Why give them the opportunity to go wrong? If they are that bad, they probably don't even need this as a starting place. You can't use code to prevent stupidity. The real dangerous situation isn't even the obvious (to me) problem with compound PKs themselves. It is when you discover that your Whatzawhozit entity needs a to-one relationship to the UserRole. Whatzawhozit is now is required to have a compound-FK. That's fine too. No big deal. It properly expresses the relationship of two entities and, as you always say, FKs are just implementation artifacts of a RDBMS. Ignore them. Let EOF worry about them. Your job as a WO developer is to worry about EOs! Then one day a new WO dev comes along and says Well, gee golly! I have the FK for both User and Role! I'll just create
Re: Delete rules on flattened relationships
On 2011-11-16, at 8:24 PM, David Avendasora wrote: On Nov 17, 2011, at 7:48 AM, Paul Hoadley wrote: On 17/11/2011, at 10:08 AM, David Avendasora wrote: On Nov 10, 2011, at 5:34 AM, Paul Hoadley wrote: Say I have two entities, User and Role, and a joining entity UserRole to create a many-to-many relationship between them. So I have a relationship 'userRoles' from User to UserRole (and a relationship 'userRoles' from Role back to UserRole). I flatten the relationship on User, so I also have a 'roles' relationship on that entity. Wait. Also?!? That's insane. That's two distinct relationships representing the same DB information, and one is hiding a huge piece of the action. You are just asking for trouble. User.userRoles is not a class property. All that's exposed is the flattened User.roles. Okay, then that should be alright then, and I think nullify is the proper setting for the non-class real relationships. I don't _think_ I'm talking about anything particularly unusual here, just the standard result of creating a many-to-many relationship with Entity Modeler, with a join entity and Flatten relationships checked. Not unusual, just something that you really shouldn't even be thinking about. That's what flattened relationships do to you. I don't like them. Every time I've tried to use them, I end up regretting it. I find it much better to leave the real relationship and write cover methods that approximate what flattening it would have done. That many-to-many join entity always seems to end up having additional parameters, or be just the right place to put a certain piece of business logic. Then I have to refactor everything that was dependent upon the flattened relationship. I have very rarely had that need to change a to-many relationship. In my experience, they are just an implementation artifact from having to use an RDBMS to store an object graph. Flattening and hiding the join table avoids adding artificial constructs to the Java code. A Good Thing (tm) IMO. Now if the join table is a real object in your system, then by all means don't flatten. That and flattening mandates that you use compound primary keys, which are Evil. I will argue that they are not evil if they consist only of immutable FKs. Otherwise, yes, avoid them unless you have a really good reason not to. And even then they must be immutable. Evil like Vertical Inheritance and running without containment on your reactor … er … I mean without FK constraints defined in the database (yes, that was aimed at all you MySQL/MSSQL Reavers out there). All these technologies/features reside in the Eighth Circle of Hell (8th trench, to be specific.). They seem to be great time/money savers, but in the end they bind you to servicing their restrictive shortcomings and tempt you into further wobauchery like compound Foreign Keys and sharing individual attributes of compound Foreign Keys between multiple relationships. It's just sick what some people will do. That sounds like The Voice of Experience. :-P I firmly believe that the only time you should use any of them is when you are given a legacy database that you have to write an app for. If you are creating the db to support your own App, don't be tempted by their siren call. I know that it's not a popular view, and likely Chuck or Mike or many others with greater experience will say that they can be used safely. Yes, they can. And should be. They'll say things like Flattened Many-to-Many Relationships don't kill apps, Developers kill apps. Flattened Many-to-Many Relationships don't kill apps, Davids kill apps. Flattened Many-toManys just make it so much easier. ... to write WO applications, yes. Chuck -- Chuck Hill Senior Consultant / VP Development Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Delete rules on flattened relationships
On Nov 18, 2011, at 2:10 AM, Chuck Hill wrote: On 2011-11-16, at 8:24 PM, David Avendasora wrote: On Nov 17, 2011, at 7:48 AM, Paul Hoadley wrote: On 17/11/2011, at 10:08 AM, David Avendasora wrote: On Nov 10, 2011, at 5:34 AM, Paul Hoadley wrote: Say I have two entities, User and Role, and a joining entity UserRole to create a many-to-many relationship between them. So I have a relationship 'userRoles' from User to UserRole (and a relationship 'userRoles' from Role back to UserRole). I flatten the relationship on User, so I also have a 'roles' relationship on that entity. Wait. Also?!? That's insane. That's two distinct relationships representing the same DB information, and one is hiding a huge piece of the action. You are just asking for trouble. User.userRoles is not a class property. All that's exposed is the flattened User.roles. Okay, then that should be alright then, and I think nullify is the proper setting for the non-class real relationships. I don't _think_ I'm talking about anything particularly unusual here, just the standard result of creating a many-to-many relationship with Entity Modeler, with a join entity and Flatten relationships checked. Not unusual, just something that you really shouldn't even be thinking about. That's what flattened relationships do to you. I don't like them. Every time I've tried to use them, I end up regretting it. I find it much better to leave the real relationship and write cover methods that approximate what flattening it would have done. That many-to-many join entity always seems to end up having additional parameters, or be just the right place to put a certain piece of business logic. Then I have to refactor everything that was dependent upon the flattened relationship. I have very rarely had that need to change a to-many relationship. In my experience, they are just an implementation artifact from having to use an RDBMS to store an object graph. Flattening and hiding the join table avoids adding artificial constructs to the Java code. A Good Thing (tm) IMO. Now if the join table is a real object in your system, then by all means don't flatten. Huh. I guess our experiences with many-to-many relationships is just different. Every (seriously, every!) time I've said I'll never need more attributes on, or relationships from or to this many-to-many join entity, I discover some requirement that mandates it. I have to disagree that because the join table is an implementation artifact that it can be ignored. I often times thing that a well conceived model gives the same level of importance to relationships between entities as the entities themselves. How long have these objects been related? Is it an active relationship? What type of relationship is it? Will it stop being active? There's a lot of meta data surrounding a relationship and a join table is the perfect place to carry it. Maybe that information isn't needed now, but what about later? Do you trust that the next developer isn't going to just add some attributes or additional relationships and leave the compound-PK in place? I don't trust the next dev. Why give them the opportunity to go wrong? The real dangerous situation isn't even the obvious (to me) problem with compound PKs themselves. It is when you discover that your Whatzawhozit entity needs a to-one relationship to the UserRole. Whatzawhozit is now is required to have a compound-FK. That's fine too. No big deal. It properly expresses the relationship of two entities and, as you always say, FKs are just implementation artifacts of a RDBMS. Ignore them. Let EOF worry about them. Your job as a WO developer is to worry about EOs! Then one day a new WO dev comes along and says Well, gee golly! I have the FK for both User and Role! I'll just create two to-one relationships directly to User and Role. Why mess with going through UserRole to get them? That's just DB overhead I don't need to do! I am an optimization genius! And so begins the mouldering of your model. A few days/weeks/months/years later a new requirement comes up Oh hey, Whatzawhozit also needs a relationship to the many-to-many UserDepartment entity. Okay, it already knows the userID so I can use that as half of this compound-FK too. Look at how smart I am to keep my DB so nicely normalized! No duplicate data! Pretty soon the Whatzawhozit userID attribute (hopefully it's not a class property, but userID is such a useful real-world number … I digress) is participating in 3 different FKs and the database is well and truly fucked, only nobody knows it yet because it's very likely that not _every_ transaction corrupts the database. Maybe users will get some weird validation errors on things they weren't even trying to change, but that can be entirely dependent upon your delete rules, ownership settings and the non-deterministic sequence in which EOF executes updates! If
Re: Delete rules on flattened relationships
On 2011-11-16, at 3:38 PM, David Avendasora wrote: On Nov 10, 2011, at 5:34 AM, Paul Hoadley wrote: Say I have two entities, User and Role, and a joining entity UserRole to create a many-to-many relationship between them. So I have a relationship 'userRoles' from User to UserRole (and a relationship 'userRoles' from Role back to UserRole). I flatten the relationship on User, so I also have a 'roles' relationship on that entity. Wait. Also?!? That's insane. That's two distinct relationships representing the same DB information, and one is hiding a huge piece of the action. You are just asking for trouble. I am hopeful that one of them is just in the model, you know, normal flattening through a join table? Pick one. Get rid of the other. I vote for getting rid of the flattened relationship. I find flattened relationships to be on the same level as compound PKs. Sure they seem great, but eventually they come back to bite you. They paint you into a long-term corner for short-term convenience sake. Except when hiding key only join tables. Proper relationship molding seems simple, Yep, just get them damp and put them someplace warm and dark. but it is full of subtleties and complexities and you can easily do things that work fine in all but a few specific conditions and then they can corrupt your data without you knowing it until it's too late. Having two relationships that represent the same information makes database corruption at least 10x more likely. Here's Dave's Rules of Happy Modeling™ * 1) No flattened relationships 2) No compound primary keys 3) One path to data (no cyclical relationships) No foo.bar.foo? What if you have a Foo and want the Bar? 4) Model Inheritance only as the very last resort. Pfft. Use inheritance where is makes sense (Liskov sense, not for implementation or when you really want a Role). *Oftentimes you are stuck with an existing/legacy DB and it is great that WO gives you the tools to work with a sub-optimal (from an OO perspective) architecture, but you should be very hesitant to use those tools when creating a new architecture. True. But I want to hear more about relationship molding. I wonder if attributes would mold too Chuck -- Chuck Hill Senior Consultant / VP Development Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Delete rules on flattened relationships
On 2011-11-09, at 4:08 PM, Paul Hoadley wrote: On 10/11/2011, at 8:25 AM, Ramsey Gurley wrote: Say I have two entities, User and Role, and a joining entity UserRole to create a many-to-many relationship between them. So I have a relationship 'userRoles' from User to UserRole (and a relationship 'userRoles' from Role back to UserRole). I flatten the relationship on User, so I also have a 'roles' relationship on that entity. So User.userRoles and Role.userRoles are not class attributes, right? They are just modelled. User.roles and Role.users are the to-many relationships that you see in the Java code. Say I delete a User. I want User.userRoles to Cascade. And I want both UserRole.user and UserRole.role to Nullify. And at that point, isn't the work done? So in this case, wouldn't I want No Action on User.roles? And hence isn't this a counter-example to your advice above? (It may well not be—tell me if I'm wrong!) This is making my head hurt. I have the public to-many User.roles as Nullify. I was under the impression that you needed that to remove that User from the Role.users relationship. But I could be wrong. That might just be a habit. The non-class attribute User.userRoles is set to Cascade. The to-one relationships from UserRole to User and to Role is Nullify. I looked a second time. The cascade is actually on the non-class property. The flattened is nullify... so maybe it would work with no action. I'm not recommending anything, just noting something I saw which seemed odd. Sorry, not trying to pin you down to anything! In my example above, because UserRole.role is Nullify, probably having User.roles set to Nullify would not make any difference. I would have to work a bit hard to contrive an example where it mattered. Say if UserRole.role was Cascade (obviously it wouldn't be)—then if User.roles was Nullify they would conflict, but if it was No Action, the Cascade would happen. Obviously you could look at each flattened relationship on a case-by-case basis. I'm just trying to tease out whether No Action would be correct 100% of the time, as long as you had the right delete rules along the chain of actual relationships that constituted the flattened relationship. -- Chuck Hill Senior Consultant / VP Development Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Delete rules on flattened relationships
On 17/11/2011, at 1:21 PM, Chuck Hill wrote: Say I have two entities, User and Role, and a joining entity UserRole to create a many-to-many relationship between them. So I have a relationship 'userRoles' from User to UserRole (and a relationship 'userRoles' from Role back to UserRole). I flatten the relationship on User, so I also have a 'roles' relationship on that entity. So User.userRoles and Role.userRoles are not class attributes, right? They are just modelled. User.roles and Role.users are the to-many relationships that you see in the Java code. Correct. Say I delete a User. I want User.userRoles to Cascade. And I want both UserRole.user and UserRole.role to Nullify. And at that point, isn't the work done? So in this case, wouldn't I want No Action on User.roles? And hence isn't this a counter-example to your advice above? (It may well not be—tell me if I'm wrong!) This is making my head hurt. I have the public to-many User.roles as Nullify. Yeah, that's what Entity Modeler will give you as the default. I was under the impression that you needed that to remove that User from the Role.users relationship. But I could be wrong. That might just be a habit. I forced myself to sit down and write a test app. You're completely correct. Problem solved. The non-class attribute User.userRoles is set to Cascade. The to-one relationships from UserRole to User and to Role is Nullify. (Yeah.) To summarise, my original question amounted to, Do you really need to think about whether the delete rules on the flattened and the underlying relationships are consistent, couldn't you just set the flattened to No Action? And the answer is: No, you really need to think about it and make sure they're consistent. Thanks Ramsey, Dave, and Chuck. -- Paul. http://logicsquad.net/ ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Delete rules on flattened relationships
On Nov 17, 2011, at 7:48 AM, Paul Hoadley wrote: On 17/11/2011, at 10:08 AM, David Avendasora wrote: On Nov 10, 2011, at 5:34 AM, Paul Hoadley wrote: Say I have two entities, User and Role, and a joining entity UserRole to create a many-to-many relationship between them. So I have a relationship 'userRoles' from User to UserRole (and a relationship 'userRoles' from Role back to UserRole). I flatten the relationship on User, so I also have a 'roles' relationship on that entity. Wait. Also?!? That's insane. That's two distinct relationships representing the same DB information, and one is hiding a huge piece of the action. You are just asking for trouble. User.userRoles is not a class property. All that's exposed is the flattened User.roles. Okay, then that should be alright then, and I think nullify is the proper setting for the non-class real relationships. I don't _think_ I'm talking about anything particularly unusual here, just the standard result of creating a many-to-many relationship with Entity Modeler, with a join entity and Flatten relationships checked. Not unusual, just something that you really shouldn't even be thinking about. That's what flattened relationships do to you. I don't like them. Every time I've tried to use them, I end up regretting it. I find it much better to leave the real relationship and write cover methods that approximate what flattening it would have done. That many-to-many join entity always seems to end up having additional parameters, or be just the right place to put a certain piece of business logic. Then I have to refactor everything that was dependent upon the flattened relationship. That and flattening mandates that you use compound primary keys, which are Evil. Evil like Vertical Inheritance and running without containment on your reactor … er … I mean without FK constraints defined in the database (yes, that was aimed at all you MySQL/MSSQL Reavers out there). All these technologies/features reside in the Eighth Circle of Hell (8th trench, to be specific.). They seem to be great time/money savers, but in the end they bind you to servicing their restrictive shortcomings and tempt you into further wobauchery like compound Foreign Keys and sharing individual attributes of compound Foreign Keys between multiple relationships. It's just sick what some people will do. I firmly believe that the only time you should use any of them is when you are given a legacy database that you have to write an app for. If you are creating the db to support your own App, don't be tempted by their siren call. I know that it's not a popular view, and likely Chuck or Mike or many others with greater experience will say that they can be used safely. They'll say things like Flattened Many-to-Many Relationships don't kill apps, Developers kill apps. Flattened Many-toManys just make it so much easier. Dave ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Delete rules on flattened relationships
On 17/11/2011, at 2:54 PM, David Avendasora wrote: On Nov 17, 2011, at 7:48 AM, Paul Hoadley wrote: On 17/11/2011, at 10:08 AM, David Avendasora wrote: On Nov 10, 2011, at 5:34 AM, Paul Hoadley wrote: Say I have two entities, User and Role, and a joining entity UserRole to create a many-to-many relationship between them. So I have a relationship 'userRoles' from User to UserRole (and a relationship 'userRoles' from Role back to UserRole). I flatten the relationship on User, so I also have a 'roles' relationship on that entity. Wait. Also?!? That's insane. That's two distinct relationships representing the same DB information, and one is hiding a huge piece of the action. You are just asking for trouble. User.userRoles is not a class property. All that's exposed is the flattened User.roles. Okay, then that should be alright then, and I think nullify is the proper setting for the non-class real relationships. (I think I've now officially confused everyone, and kind of regret starting this thread...) No, you want Cascade on the non-class real relationships (to remove the row in the join table), and Nullify on the flattened relationship—as Chuck noted, to remove the destination object from the flattened relationship. I don't _think_ I'm talking about anything particularly unusual here, just the standard result of creating a many-to-many relationship with Entity Modeler, with a join entity and Flatten relationships checked. Not unusual, just something that you really shouldn't even be thinking about. Point taken, though someone has to think about it at some point. I thought the default delete rule (Nullify) was wrong. Turns out I was incorrect. :-) -- Paul. http://logicsquad.net/ ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Delete rules on flattened relationships
On Nov 17, 2011, at 1:40 PM, Paul Hoadley wrote: On 17/11/2011, at 2:54 PM, David Avendasora wrote: On Nov 17, 2011, at 7:48 AM, Paul Hoadley wrote: On 17/11/2011, at 10:08 AM, David Avendasora wrote: On Nov 10, 2011, at 5:34 AM, Paul Hoadley wrote: Say I have two entities, User and Role, and a joining entity UserRole to create a many-to-many relationship between them. So I have a relationship 'userRoles' from User to UserRole (and a relationship 'userRoles' from Role back to UserRole). I flatten the relationship on User, so I also have a 'roles' relationship on that entity. Wait. Also?!? That's insane. That's two distinct relationships representing the same DB information, and one is hiding a huge piece of the action. You are just asking for trouble. User.userRoles is not a class property. All that's exposed is the flattened User.roles. Okay, then that should be alright then, and I think nullify is the proper setting for the non-class real relationships. (I think I've now officially confused everyone, and kind of regret starting this thread...) No, you want Cascade on the non-class real relationships (to remove the row in the join table), and Nullify on the flattened relationship—as Chuck noted, to remove the destination object from the flattened relationship. Ahg! I was meaning nullify on the the UserRole.user and UserRole.role relationships. The User.userRoles() and Role.userRoles() should be cascade, owns and propagate PK. The User.roles(), Role.users() relationships … well, I'll take your word for it. Especially seeing as how you went and tested it. :-) I don't _think_ I'm talking about anything particularly unusual here, just the standard result of creating a many-to-many relationship with Entity Modeler, with a join entity and Flatten relationships checked. Not unusual, just something that you really shouldn't even be thinking about. Point taken, though someone has to think about it at some point. I thought the default delete rule (Nullify) was wrong. Turns out I was incorrect. :-) But if you didn't flatten the relationship it wouldn't have been there to think about. That's what I'm trying to say. Flattening doesn't save time / work / grief, it just shifts it. Dave ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Delete rules on flattened relationships
On Nov 17, 2011, at 10:42 AM, Chuck Hill wrote: On 2011-11-16, at 3:38 PM, David Avendasora wrote: On Nov 10, 2011, at 5:34 AM, Paul Hoadley wrote: Say I have two entities, User and Role, and a joining entity UserRole to create a many-to-many relationship between them. So I have a relationship 'userRoles' from User to UserRole (and a relationship 'userRoles' from Role back to UserRole). I flatten the relationship on User, so I also have a 'roles' relationship on that entity. Wait. Also?!? That's insane. That's two distinct relationships representing the same DB information, and one is hiding a huge piece of the action. You are just asking for trouble. I am hopeful that one of them is just in the model, you know, normal flattening through a join table? I thought he was saying they were both class attributes. Since they're not, they are as safe as flattening can be. Safe as far as EOF is concerned, that is. Pick one. Get rid of the other. I vote for getting rid of the flattened relationship. I find flattened relationships to be on the same level as compound PKs. Sure they seem great, but eventually they come back to bite you. They paint you into a long-term corner for short-term convenience sake. Except when hiding key only join tables. In my experience key-only join tables are like not nearly as common as most developers think. Sure in a first draft of a model there's lots of key-only joins, but as the model matures and requirements and business logic becomes more clear, there is almost always another attribute to tack on there, like UserRole.status, or UserRole.type or… whatever. Proper relationship molding seems simple, Yep, just get them damp and put them someplace warm and dark. Or make it a key-only join table with a compound PK and your model will begin to rot before your eyes. but it is full of subtleties and complexities and you can easily do things that work fine in all but a few specific conditions and then they can corrupt your data without you knowing it until it's too late. Having two relationships that represent the same information makes database corruption at least 10x more likely. Here's Dave's Rules of Happy Modeling™ * 1) No flattened relationships 2) No compound primary keys 3) One path to data (no cyclical relationships) No foo.bar.foo? What if you have a Foo and want the Bar? Let me be more specific: don't model something where following the relationships ends you back at the *exact same instance* of an entity. Obviously you may end up back at the same Entity, but ending up at the exact same object means you've probably got something conceptually wrong in the model. 4) Model Inheritance only as the very last resort. Pfft. Use inheritance where is makes sense (Liskov sense, not for implementation or when you really want a Role). Let me clarify. Look at all the other possibilities for modeling the relationship between to Entities first and be sure they don't apply before you chose Inheritance. I've made the mistake of jumping to Inheritance to quickly more than once (you're shocked, I know). Unlike the fabled key-only join table, Inheritance sometimes is the right tool, but the developer should prove that two entities truly have an is-a relationship. Is-a relationships are very rigid and are difficult to change if/when you discover that it was wrong. Has-a relationships are much more flexible. In fact, I'll posit that inheritance really doesn't exist in the real world so modeling a relationship as such is always flawed. There are just too many exceptions. Business requirements and logic are constantly shifting. With that said, all models are flawed by definition. They are models, not true representations of the real world. That is the art of data / entity relationship / object modeling. Discovering the model that most closely represents the real world, but is flexible enough to bend and shift with the inevitable changes to requirements. Inheritance limits that flexibility. Sometimes that is actually good, though. Inheritance is much more useful as a code structure in the view and controller layer. There it is immensely useful and proper use of it usually increases flexibility and reusability. *Oftentimes you are stuck with an existing/legacy DB and it is great that WO gives you the tools to work with a sub-optimal (from an OO perspective) architecture, but you should be very hesitant to use those tools when creating a new architecture. True. But I want to hear more about relationship molding. I wonder if attributes would mold too…. I'd say a class-property Foreign Keys are simply made of mold. Compound PKs and FKs mold quickly, usually due to the moist heat of shifting business requirements. Dave ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list
Re: Delete rules on flattened relationships
On 10/11/2011, at 10:38 AM, Paul Hoadley wrote: Obviously you could look at each flattened relationship on a case-by-case basis. I'm just trying to tease out whether No Action would be correct 100% of the time, as long as you had the right delete rules along the chain of actual relationships that constituted the flattened relationship. Come on Chuck, you know you want to jump in on this thread. :-) Am I so completely off-base here that no one wants to converse with the crazy person, or is this just something no one pays much attention to? -- Paul. http://logicsquad.net/ ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Delete rules on flattened relationships
On Nov 8, 2011, at 8:34 PM, Paul Hoadley wrote: Hello, I was recently reviewing an EO model of mine and noticed a flattened relationship with a Nullify delete rule. I recalled part of an exchange between Davids Avendasora and LeBer earlier this year: And what should those be for the flattened relationship? I'm guessing that they should be nullify or do nothing Yes, only one delete rule should affect a given relationship. In fact, I always shy away from (nay, avoid completely) flattened relationships that hide objects I am actually interested in. In general, 'one path to the object' is the rule I try to follow. So the advice is that the intended delete rule(s) should operate on the real relationship chain, not shortcut via the flattened relationship. That's fine, but are Nullify and Do Nothing really interchangeable on a flattened relationship, as it's almost suggested above? It's important because the default is Nullify, so all flattened relationships have that rule unless you change them. But depending on whether that rule is applied before or after the rule(s) applied over the real relationship chain, Nullify might end up giving you the wrong semantics. Shouldn't all flattened relationships have a Do Nothing delete rule (at least by default)? -- Paul. http://logicsquad.net/ Not all... at least not flattened many to many. Those cascade. Which led me to a surprising find as well. The opposite side of that cascade is nullify, which I thought was incompatible with cascade. But, evidently, it works and I can see why it would be needed on the other side of the delete. Ramsey ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Delete rules on flattened relationships
Hi Ramsey, On 10/11/2011, at 4:24 AM, Ramsey Gurley wrote: On Nov 8, 2011, at 8:34 PM, Paul Hoadley wrote: So the advice is that the intended delete rule(s) should operate on the real relationship chain, not shortcut via the flattened relationship. That's fine, but are Nullify and Do Nothing really interchangeable on a flattened relationship, as it's almost suggested above? It's important because the default is Nullify, so all flattened relationships have that rule unless you change them. But depending on whether that rule is applied before or after the rule(s) applied over the real relationship chain, Nullify might end up giving you the wrong semantics. Shouldn't all flattened relationships have a Do Nothing delete rule (at least by default)? Not all... at least not flattened many to many. Those cascade. Which led me to a surprising find as well. The opposite side of that cascade is nullify, which I thought was incompatible with cascade. But, evidently, it works and I can see why it would be needed on the other side of the delete. Say I have two entities, User and Role, and a joining entity UserRole to create a many-to-many relationship between them. So I have a relationship 'userRoles' from User to UserRole (and a relationship 'userRoles' from Role back to UserRole). I flatten the relationship on User, so I also have a 'roles' relationship on that entity. Say I delete a User. I want User.userRoles to Cascade. And I want both UserRole.user and UserRole.role to Nullify. And at that point, isn't the work done? So in this case, wouldn't I want No Action on User.roles? And hence isn't this a counter-example to your advice above? (It may well not be—tell me if I'm wrong!) -- Paul. http://logicsquad.net/ ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Delete rules on flattened relationships
On Nov 9, 2011, at 2:34 PM, Paul Hoadley wrote: Hi Ramsey, On 10/11/2011, at 4:24 AM, Ramsey Gurley wrote: On Nov 8, 2011, at 8:34 PM, Paul Hoadley wrote: So the advice is that the intended delete rule(s) should operate on the real relationship chain, not shortcut via the flattened relationship. That's fine, but are Nullify and Do Nothing really interchangeable on a flattened relationship, as it's almost suggested above? It's important because the default is Nullify, so all flattened relationships have that rule unless you change them. But depending on whether that rule is applied before or after the rule(s) applied over the real relationship chain, Nullify might end up giving you the wrong semantics. Shouldn't all flattened relationships have a Do Nothing delete rule (at least by default)? Not all... at least not flattened many to many. Those cascade. Which led me to a surprising find as well. The opposite side of that cascade is nullify, which I thought was incompatible with cascade. But, evidently, it works and I can see why it would be needed on the other side of the delete. Say I have two entities, User and Role, and a joining entity UserRole to create a many-to-many relationship between them. So I have a relationship 'userRoles' from User to UserRole (and a relationship 'userRoles' from Role back to UserRole). I flatten the relationship on User, so I also have a 'roles' relationship on that entity. Say I delete a User. I want User.userRoles to Cascade. And I want both UserRole.user and UserRole.role to Nullify. And at that point, isn't the work done? So in this case, wouldn't I want No Action on User.roles? And hence isn't this a counter-example to your advice above? (It may well not be—tell me if I'm wrong!) I looked a second time. The cascade is actually on the non-class property. The flattened is nullify... so maybe it would work with no action. I'm not recommending anything, just noting something I saw which seemed odd. Ramsey ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Delete rules on flattened relationships
On 10/11/2011, at 8:25 AM, Ramsey Gurley wrote: Say I have two entities, User and Role, and a joining entity UserRole to create a many-to-many relationship between them. So I have a relationship 'userRoles' from User to UserRole (and a relationship 'userRoles' from Role back to UserRole). I flatten the relationship on User, so I also have a 'roles' relationship on that entity. Say I delete a User. I want User.userRoles to Cascade. And I want both UserRole.user and UserRole.role to Nullify. And at that point, isn't the work done? So in this case, wouldn't I want No Action on User.roles? And hence isn't this a counter-example to your advice above? (It may well not be—tell me if I'm wrong!) I looked a second time. The cascade is actually on the non-class property. The flattened is nullify... so maybe it would work with no action. I'm not recommending anything, just noting something I saw which seemed odd. Sorry, not trying to pin you down to anything! In my example above, because UserRole.role is Nullify, probably having User.roles set to Nullify would not make any difference. I would have to work a bit hard to contrive an example where it mattered. Say if UserRole.role was Cascade (obviously it wouldn't be)—then if User.roles was Nullify they would conflict, but if it was No Action, the Cascade would happen. Obviously you could look at each flattened relationship on a case-by-case basis. I'm just trying to tease out whether No Action would be correct 100% of the time, as long as you had the right delete rules along the chain of actual relationships that constituted the flattened relationship. -- Paul. http://logicsquad.net/ ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
