Re: Delete rules on flattened relationships
Re: Delete rules on flattened relationships
- Subject: Re: Delete rules on flattened relationships
- From: David Avendasora <email@hidden>
- Date: Fri, 18 Nov 2011 12:09:55 +0800
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 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.
>> 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 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden