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

[cowwoc <cowwoc@xxxxxxxxxxxxxxxx>]

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
> 
> 

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