I'm happy to model an optional to-one as a to-many. It almost always
results in a superior data model because it moves contention off the,
e.g., Part, table. That is good and sometimes very good (my example
is a User table with lots of rows and optional to-one's that grow
like topsy as marketeers devise new user attributes to add). Good
data design vs. the cost of a few lines of code for cover methods is
a win every time.
I think you need a better example because I'm left wondering how/when
PartAttribute and Part rows get created and deleted. If some process
outside your control is doing that the to-many is off the table and
there are other issues that need to be addressed. If there aren't
other processes outside your control, why not right the wrongs of the
original design?
Tom
On Jan 13, 2010, at 4:01 PM, Lon Varscsak wrote:
Okay, let me try to give an example (although a contrived example).
Entity: Part (PK: partNumber)
Entity: PartAttributes (PK: partNumber)
It's a to-one relationship from Part to PartAttributes, but the
part_attributes table doesn't have to have a row for a given part.
If this were a to-many relationship this would result in just an
empty NSArray<PartAttributes>. I want partAttributes() to return
null.
In the old days the only way to model this was to have a to-many
relationship with methods that allow the user to access the data in
a to-one way ([[somePart partAttributes] lastObject]). Or you
could but an exception handler in:
- (PartAttributes *)partAttributes {
NS_DURING
[partAttributes self]; //this would catch the exception thrown
NS_HANDLER
[partAttributes release]; //throws away the fault
partAttributes = nil; //sets the ivar to nil
NS_ENDHANDLER
return partAttributes;
}
I was just wondering if this concept of a PK to PK to-one
relationship was possible these days without jumping through
hoops. For this example I probably wouldn't setup the tables this
way in RL, but there are situations where it is valuable and when
dealing with legacy table structures you don't usually have a choice.
-Lon
On Wed, Jan 13, 2010 at 4:49 PM, Chuck Hill <ch...@global-
village.net> wrote:
Modelling it as FK to PK seems like the way to go, unless I am
misunderstanding what you need.
On Jan 13, 2010, at 3:24 PM, Lon Varscsak wrote:
Yes it is the same PK in both tables but there are no rows in the
relationship. This is a pretty common practice and I just hate
modeling a to-many and then provide interfaces as a to-one.
On Wed, Jan 13, 2010 at 4:14 PM, Travis Britt <tbr...@phigment.org>
wrote:
Short answer: no. Is the PK not really a PK? If it is a real PK,
how are there rows without it?
On Jan 13, 2010, at 5:53 PM, Lon Varscsak wrote:
> Is there a way to model an optional to-one relationship from the
primary key to a primary key of another object?
_______________________________________________
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/chill%
40global-village.net
This email sent to ch...@global-village.net
--
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/blenko%
40martingalesystems.com
This email sent to ble...@martingalesystems.com
_______________________________________________
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
