Re: [eclipselink-users] @ManyToMany relationship for a List?

[cowwoc <cowwoc@xxxxxxxxxxxxxxxx>]

I think I see it now. I guess I was confused by:

class PlaylistItem
{
  @OneToOne
  public Video getVideo();
}

I thought @OneToOne meant that there may only be one PlaylistItem for every
Video but (correct me if I'm wrong) what @OneToOne actually means is that
there that every PlaylistItem has exactly one Video associated with it.
**The relationship says nothing about the association from the remote end**
Is that correct?

PS: What's the difference on a table-level between @ManyToOne and @OneToOne?
Don't they both result in the same schema in this case?

I mentioned @ManyToOne would result in:

Playlist[id]
Video[id]
PlaylistItem[id, playlist_id, video_id]

Wouldn't @OneToOne result in the same?

Thanks,
Gili


Tom Ware wrote:
> 
> Hi Gili,
> 
>    Depending on how you want things to work, it is certainly possible to
> do it 
> the way you have suggested.  Let me explain a bit further my suggestion,
> and 
> then you can decide which fits your model better.
> 
> - PlayList has a OneToMany to PlayListItem
> - PlayListItem has a OneToOne to Video
> - PlayListItem has its own identity.
> 
> Consider the following objects:
> - PlayList: PL1
> - Video: V1
> - Video: V2
> 
> Lets say we want to add V1 to PL1:
> 
> 1. pl1.add(v1)
> - on this call, we create an instance of PlayListItem pli1 and associate
> it with 
> v1:
> - pli1 = new PlayListItem()
> - pli1.video = v1
> - we then associate pli1 to pl1.
> - pl1.addPlayListItem(pli1)
> 
> 2. p11.add(v2)
> - we do basically the same thing as above:
> - pli2 = new PlayListItem()
> - pli2.video = v2
> - pl1.addPlayListItem(pli2)
> 
> 3. pl1.add(v1)
> - add a duplicate item
> - pli3 = new PlayListItem() // this will have a different PK than pli1
> - pli3.video = v1
> - pl1.addPlayListItem(pli3)
> - The key here is keys that form the list are the foreign keys on PlayList
> and 
> PlayListItem, so you do not get conflicts where there are duplicate items. 
> PlayListItem has separate foreign keys that associate it with Video.
> 
> When we are done:
> 
> pl1 has a list of 3 PlayListItems (pli1, pli2, pli3)
> pli1 has a 1-1 relationship with v1
> pli2 has a 1-1 relationship with v2
> pli3 has a 1-1 relationship with v1
> 
> With this set of mappings, pl1 hold 2 pointers to v1
> 
> HTH,
> Tom
> 
> 
> cowwoc wrote:
>> Sorry, I meant to say that "PlaylistItem has a ManyToOne to Video".
>> 
>> Gili
>> 
>> 
>> cowwoc wrote:
>>>
>>> I don't understand how "PlayListItem has a OneToOne to Video" would
>>> work.
>>> Each video can be associated with multiple playlists. As a consequence,
>>> each PlaylistItem would need to be associated with multiple videos as
>>> well. Shouldn't I do this instead?
>>>
>>> Playlist has a OneToMany to PlaylistItem
>>> PlaylistItem has a OneToMany to Video
>>> PlaylistItem has its own identity
>>>
>>> This would give you:
>>>
>>> Playlist[id]
>>> Video[id]
>>> PlaylistItem[id, playlist_id, video_id]
>>>
>>> What do you think?
>>>
>>> Gili
>>>
>>>
>>> Tom Ware wrote:
>>>> Hi Gili,
>>>>
>>>>    One workaround I can think of is to add another level of
>>>> indirection.
>>>>
>>>> i.e.
>>>>
>>>> PlayList has a OneToMany to PlayListItem
>>>> PlayListItem has a OneToOne to Video
>>>> PlayListItem has its own identity.
>>>>
>>>> You could even implement the mthods in PlayList to make PlayListItem
>>>> pretty much 
>>>> transparent to whoever was using your model.
>>>>
>>>> -Tom
>>>>
>>>> cowwoc wrote:
>>>>> BTW: Short-term, I would be quite happy to settle for a simple
>>>>> workaround
>>>>> than waiting for a fix, though if the fix is as simple to implement as
>>>>> I
>>>>> mentioned (dropping the primary key, adding an id) then I'd be even
>>>>> happier
>>>>> if you could implement it in the near future :)
>>>>>
>>>>> This issue is very pressing for me right now because I don't see a
>>>>> simple
>>>>> workaround and my customer requires this feature (a single playlist to
>>>>> allow
>>>>> duplicate videos).
>>>>>
>>>>> Gili
>>>>>
>>>>>
>>>>> cowwoc wrote:
>>>>>> James Sutherland wrote:
>>>>>>> technically it is possible on a ManyToMany or when using a join
>>>>>>> table,
>>>>>>> but still rare for most models to want this.  I'm not certain what
>>>>>>> the
>>>>>>> JPA spec infers on duplicate support, but I assume it is either not
>>>>>>> supported, or not required, or more likely unspecified.
>>>>>>>
>>>>>> I think the spec implies it. Looking at sections 2.1.8.5.1 and
>>>>>> 2.1.8.5.2
>>>>>> compare the contents of "The following mapping defaults apply"
>>>>>> paragraphs.
>>>>>> You will notice that the last sentence of 2.1.8.5.1 requires a unique
>>>>>> key
>>>>>> constraint whereas 2.1.8.5.2 does not. I am asking precisely for
>>>>>> this:
>>>>>> @ManyToMany should *not* enforce a unique constraint on pair of
>>>>>> foreign
>>>>>> keys. Removing the primary key should be enough to satisfy this
>>>>>> requirement.
>>>>>>
>>>>>>
>>>>>> James Sutherland wrote:
>>>>>>> The main issue for relational is that things become tricky, i.e.
>>>>>>> insertion may work, but if you remove one of the duplicates, you now
> 
>>>>>>> need
>>>>>>> to delete them all, then insert n-1 back.
>>>>>>>
>>>>>> I think you're making it more complicated than it needs to be.
>>>>>> Instead
>>>>>> of
>>>>>> having a table with two foreign keys all you'd need is: [id, key1,
>>>>>> key2]
>>>>>> where id is the primary key. You then issue a query that returns the
>>>>>> first
>>>>>> row containing the values you'd like to delete, and delete it by its
>>>>>> id.
>>>>>>
>>>>> Gili
>>>>>
>>>>>
>>>>> cowwoc wrote:
>>>>>> FYI, I filed a bug report for the original issue:
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=256978
>>>>>>
>>>>>> Gili
>>>>>>
>>>>>>
>>>>>> cowwoc wrote:
>>>>>>> Tim Hollosy wrote:
>>>>>>>> Anyway, on to your second question. Implementing indexed lists.
>>>>>>>> What
>>>>>>>> do you mean implementing indexed lists on top of JPA?
>>>>>>>>
>>>>>>>> java.util.List is already indexed..so I don't really follow your
>>>>>>>> question.
>>>>>>>>
>>>>>>> JPA 1.0 does not retain the element index. The best you can do is
>>>>>>> @OrderBy. If the order is arbitrary (chosen by the end-user) you
>>>>>>> need
>>>>>>> to
>>>>>>> rely in ordering by indexes but currently JPA will not manage
>>>>>>> indexes
>>>>>>> for
>>>>>>> you under the hood. For example, if you want to insert an element
>>>>>>> between
>>>>>>> two other elements you will need to update the indexes of all
>>>>>>> elements
>>>>>>> that allow, etc.
>>>>>>>
>>>>>>> Gili
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> eclipselink-users mailing list
>>>> eclipselink-users@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>>>
>>>>
>>>
>> 
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> 
> 

-- 
View this message in context: http://www.nabble.com/%40ManyToMany-relationship-for-a-List--tp20749567p20780903.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.