Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] @ManyToMany relationship for a List?

Nevermind, I got it working. I now expose "List<Video>
VideoManager.getVideos(Playlist)" and the list implementation handles
PlaylistItem under the hood.

Thanks!
Gili


cowwoc wrote:
> 
> I'm going to try your approach but I don't think you can hide the details
> under the hood. If I want to add a new Playlist->Video relationship I'm
> going to need to either expose PlaylistItem to the end-user (to populate
> and save) or expose a save(Playlist, Video) method in the service layer.
> Either approach is ugly. Originally I simply used
> Playlist.getVideos().add() or remove() and the changes got persisted under
> the hood. I wish I could have a similarly clean approach (without breaking
> my layers).
> 
> 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--tp20749567p20801238.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.



Back to the top