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 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. Read that three times, still did not understand. er, what? > 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. And this did not help, at all. > 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 your really, really lucky, your DB might save your ass by throwing a FK > constraint violation, but that's assuming 2 things: > 1) The bad data being written is actually violates a FK constraint > 2) You haven't disabled your non-deferrable FK-Constraints in your > pathetic excuse for a database. > > But most likely days or weeks later you'll start getting users complaining > that the User or UserRole or UserDepartment is wrong for a given Whatzahozit > and they swear they didn't change it, or EOF starts throwing > NoSuchElementExceptions. > > All of this could have been actively prevented by the original developer if > he/she had just used a True Primary Key™ in the first place. > > Yes, I'm saying to do more work now to prevent potential obscure, hard to > diagnose bugs in the future. Not really clear on what you describing, but join tables and compound primary keys don't seem to be root cause. :-) Chuck > >>> 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 > > Yes, yes it is. That's why I'm so pertinacious about it now. I've learned by > both making the mistake myself and being stuck with a system that made it all > over the place. > >>> 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 just are worth the long-term inflexibility and danger if abused. There > are few things in EOF that I'm aware of that if misused have the potential to > do so much subtle and hard to diagnose damage as compound-PKs. And they are > soooo easy to misuse. > >>> 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." > > Can't argue with that as far as this David goes, but you might be casting too > wide a net there… :-) > >>> Flattened Many-toManys just make it so much easier. >> >> ... to write WO applications, yes. > > Yep! And quick and easy is the name of the game. > > Oh wait. No … that's Ruby on Rails. :-P > > Dave -- 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
