• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Modeling an optional to-one relationship
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Modeling an optional to-one relationship


  • Subject: Re: Modeling an optional to-one relationship
  • From: Lon Varscsak <email@hidden>
  • Date: Wed, 13 Jan 2010 17:01:23 -0700

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 <email@hidden> 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 <email@hidden> 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      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

--
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      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: Modeling an optional to-one relationship
      • From: Tom M.Blenko <email@hidden>
    • Re: Modeling an optional to-one relationship
      • From: Chuck Hill <email@hidden>
References: 
 >Modeling an optional to-one relationship (From: Lon Varscsak <email@hidden>)
 >Re: Modeling an optional to-one relationship (From: Travis Britt <email@hidden>)
 >Re: Modeling an optional to-one relationship (From: Lon Varscsak <email@hidden>)
 >Re: Modeling an optional to-one relationship (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: Objects don't get initialized sometimes
  • Next by Date: Re: Modeling an optional to-one relationship
  • Previous by thread: Re: Modeling an optional to-one relationship
  • Next by thread: Re: Modeling an optional to-one relationship
  • Index(es):
    • Date
    • Thread