Yes and no...

Yes it makes more sense, but I do not think it means what I want it to
mean (to paraphrase Inigo Montoya)...

>From how I read your pseudo-code, each LineItem can only be related to
one ProductOption.  I need to be able to relate it to many options.
My problem is trying to link *back* to the LineItem from a m2m link in
LineItem.  Since we need to identify both "ends" of the connection, I
would have to be able to identify the composite id of the LineItem.
But m2m only recognizes two links, and I'd need three (the two parts
to the line item composite id and the option id).

Ken

On Nov 12, 3:35 pm, "Mark Mandel" <[EMAIL PROTECTED]> wrote:
> Ooops!
>
> That should be manytoone! My Bad!
>
> (I did mention it was pseudo code, right?)
>
> <object name="cart>
>  <id name="uuid" />
>  <onetomany name="LineItems">
>   <link to="LineItem" />
>  </onetomany>
> </object>
>
> <object name="Product>
>  <id name="uuid" />
> </object>
>
> <object name="ProductOptions>
>  <id name="uuid" />
> </object>
>
> <object name="LineItem>
>  <compositeid>
>     <parentonetomany class="cart" />
>     <manytoone name="Product" />
>     <manytoone name="ProductOption" />
>  </compositeid>
>  <manytoone name="Product">
>    <link to="Product" />
>  </manytoone>
>  <manytoone name="ProductOption">
>    <link to="ProductOption" />
>  </manytoone>
> </object>
>
> That should make more sense now :D
>
> Mark
>
>
>
> On Thu, Nov 13, 2008 at 8:29 AM, Ken Cummins <[EMAIL PROTECTED]> wrote:
>
> > Ummm... From your earlier reply:
>
> >> <object name="LineItem>
> >>  <compositeid>
> >>     <parentonetomany class="cart" />
> >>     <onetomany name="Product" />
> >>     <onetomany name="ProductOption" />
> >>  </compositeid>
>
> > :)
>
> > But I see what you're saying about the o2m in a composite id.
>
> > And I like referential integrity, I was just curious...  :)
>
> > On Nov 12, 3:26 pm, "Mark Mandel" <[EMAIL PROTECTED]> wrote:
> >> On Thu, Nov 13, 2008 at 4:53 AM, Ken Cummins <[EMAIL PROTECTED]> wrote:
>
> >> > I *think* I understand now, but there's one problem: a compositeid
> >> > can't contain a onetomany relationship.  Only manytoone,
> >> > parentonetomany, or property.
>
> >> But there is no way a o2m could be a compositeID. The FK could never
> >> be on the table that way - its always on the child.
>
> >> > Also, as a point of clarification, should there be foreign keys set up
> >> > in the database itself, or is using the compositing of Transfer
> >> > sufficient?
>
> >> Of course you should use foreign keys... you don't like referential
> >> integrity? ;)
>
> >> Mark
> >> --
> >> E: [EMAIL PROTECTED]
> >> W:www.compoundtheory.com
>
> --
> E: [EMAIL PROTECTED]
> W:www.compoundtheory.com
--~--~---------~--~----~------------~-------~--~----~
Before posting questions to the group please read:
http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer

You received this message because you are subscribed to the Google Groups 
"transfer-dev" group.
To post to this group, send email to transfer-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/transfer-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to