Re: entity inheritance possibilities
Re: entity inheritance possibilities
- Subject: Re: entity inheritance possibilities
- From: Jonathan Rochkind <email@hidden>
- Date: Mon, 08 Sep 2003 13:35:47 -0500
Thanks for the ideas. I guess that mass PK conversion is possible, but I
still think it's more of a challenge than I want to deal with, unless I can
find no other options. [Made worse by my lack of resources; I only have one
db server]. Especially since the horizontal inheritance I'd end up with is
somewhat buggy anyway.
Let's think about some other ideas; one Ben briefly suggests, and another
that occurs to me.
1) Don't model it as a relationship at all. Instead we have two class
attributes, one for pk and one for entity name. We can easily create a
fault based on this information, for a sort of business-logic simulated
to-one relationship. I've played with this a bit in the past, and it works
reasonably well, but for some issues I'd like to find a solution for:
A) The psuedo to-one 'relationship' can't be established until the
destination is committed to the db. If the destination still has a
temporary GID, we can't save it's pk in the class attribute. This is very
inconvenient. I suppose something tricky involving listening for
notifications on pk finalization is theoretically possible, but it strikes
me that we're going to run into trouble making sure we get the final pk in
time to commit the snapshot for the source row.
B) Simulating the back-pointing conceptual to-many relationship is
hard to do in an efficient way. Sure, we can just manually create a
qualifier to fetch the 'source' objects with certain pk and entityName
attributes, but we dont' get the advantage of snapshot caching, like we
ordinarily do for to-manys. [If only you could specify a qualifier on a
_relationship_, this would be great, but you can't.]
C) We don't get the advantage of delete rules, since it isn't a
real relationship. But that can be done manually easy enough over-riding
propagateDelete..., so that's not a real problem.
But the first two are. Any ideas there?
2) A whole separate idea. Is it possible to use the _same_ fk attribute in
_multiple_ relationships? Again, we store entityName and fk in the source.
But we define a relationship to all possible destination entities, based on
that fk. Only one of them will actually be valid; which one is valid is
determined by the 'entityName' attribute, and we can use business logic to
address the proper one.
A) Is it a really bad idea to use the same source attribute in
multiple relationship definitions? Is this going to cause horrible EOF
problems?
B) It does solve the problem of being able to set the relationship
when the destination and/or the source still have temporary GIDs. since it
is a real relationship, EOF will take care of it for us.
C) The backpointing relationship is still tricky; it's basically
the same situation with the backpointing relationship in idea 1.
If anyone can follow all this and understand what I'm talking about... any
ideas or suggestions?
--Jonathan
At 11:02 AM 9/8/2003 -0700, Ben Trumbull wrote:
The PKs must be unique throughout the entire inheritance hierarchy,
regardless of type of inheritance involved.
Assuming your PKs have no intrinsic informational value, as strongly
recommended, you could perform a mapping between PKs (since you have
duplicates, it would probably be a function like entity & PK -> PK), and
copy all the objects to a new set of tables (or alter the PKs with raw SQL).
The first PK mapping function that comes to mind is (x * maxrows + PK)
where x is the index of the entity in an array of all the entities, and
maxrows is the limit of the number of rows existing in the entity with the
most rows. New rows begin after all these processed rows just like
normal EOF PK generation.
You could apply the same function to the FKs pointing into these
tables. The EOModel has all the information you need to do this
programmatically (i.e. which other tables have FKs to this set of munged
entities, and which columns are the FKs to be fixed up).
While it would be a pain, it is certainly feasible. Actually, I really
don't think this problem is as bad as you describe.
The other approach is not to make this a relationship in EOF terminology,
but instead just make it "business logic". To KVC it will look just like
a relationship. Granted, it won't be a class property.
Bill thinks you should just export the entire object graph to XML, alter
the schema, and then reimport it (leave the PK generation for these
objects automatic) and save it back to the database.
--
-Ben
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.