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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
