@ManyToMany relationship for a List?

[cowwoc]

Hi,

A playlist contains multiple music clips. And each clip may be associated with multiple playlists. I believe this should be mapped as follows:

class Playlist
{
  @ManyToMany
  @JoinTable(name="playlist_to_clip")
  List<Clip> getClips();
}

Unfortunately I can't get this to work. EclipseLink generates a "playlist_to_clip" table with two columns: playlist and clip. The primary key is the pair [playlist, clip]. In other words, it is impossible for a Playlist to contain the same Clip multiple times (which is desirable).

I find the mapping that EclipseLink generates confusing because it seems to only make sense for Sets, not Collection or List (I've tried both). If was mapping this by hand I'd add an "id" primary key column to the join table and allow duplicate [playlist, clip] combinations. Any ideas on how to implement this in EclipseLink?

Going one step further, are there existing (unofficial) libraries for implementing indexed lists on top of JPA or will I have to write this from scratch?

Thank you,
Gili

[tch]

Well, I'll refrain from offering the obvious solution - create your
own table - obviously you want DML generation, an area where I haven't
ventured much.

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.


./tch



On Sat, Nov 29, 2008 at 12:51 PM, cowwoc <cowwoc@...> wrote:

>
> Hi,
>
> A playlist contains multiple music clips. And each clip may be associated
> with multiple playlists. I believe this should be mapped as follows:
>
> class Playlist
> {
>  @ManyToMany
>  @JoinTable(name="playlist_to_clip")
>  List<Clip> getClips();
> }
>
> Unfortunately I can't get this to work. EclipseLink generates a
> "playlist_to_clip" table with two columns: playlist and clip. The primary
> key is the pair [playlist, clip]. In other words, it is impossible for a
> Playlist to contain the same Clip multiple times (which is desirable).
>
> I find the mapping that EclipseLink generates confusing because it seems to
> only make sense for Sets, not Collection or List (I've tried both). If was
> mapping this by hand I'd add an "id" primary key column to the join table
> and allow duplicate [playlist, clip] combinations. Any ideas on how to
> implement this in EclipseLink?
>
> Going one step further, are there existing (unofficial) libraries for
> implementing indexed lists on top of JPA or will I have to write this from
> scratch?
>
> Thank you,
> Gili
> --
> View this message in context: http://www.nabble.com/%40ManyToMany-relationship-for-a-List--tp20749567p20749567.html
> Sent from the EclipseLink - Users mailing list archive at Nabble.com.
>
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@...
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

[cowwoc]

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

[cowwoc]

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

[James Sutherland]

JPA 2.0 will define a special indexed List mapping.  There is an existing bug for this,

https://bugs.eclipse.org/bugs/show_bug.cgi?id=249037

Note, however that normally a List is used because it is just a more common and useful mapping, even though the items in it are assumed to be unique.  So I hope this will not change defaults, unless you annotate the mapping as being indexed.

As for supporting duplicates, that is a separate issue.  You could also have a List for a foreign key base OneToMany, but duplicates would not make sense,  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.

EclipseLink has some level of duplicate support for some of our non-relational mappings, but none currently for our relational mappings, so thank you for logging the enhancement request.  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.  Possible, but not something we have support for yet, it would probably require some sort of @AllowDuplicates option, that switch the mapping to doing a deleteAll then reinsertion on any change.  The same issue is also relevant for BasicCollection and the new JPA 2.0 ElementCollection mappings.
 



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

[cowwoc]

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


FYI, I filed a bug report for the original issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=256978

Gili



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

[cowwoc]

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

[tware]

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@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

[cowwoc]

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
[e-mail]
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

[cowwoc]

Sorry, I meant to say that "PlaylistItem has a ManyToOne to Video".

Gili



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
[e-mail]
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

[tware]

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@...
>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>>
>>>
>>
>

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

[cowwoc]

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
>>> [e-mail]
>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>>
>>>
>>
>
_______________________________________________
eclipselink-users mailing list
[e-mail]
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

[tware]

Hi Gili,

   You are correct, the OneToOne relationship from PlayListItem to Video does
not restrict how many PlayListItems can refer to the same Video.

   ManyToOne is used in JPA to be explicit about the fact that a relationship is
on the Many-side of a OneToMany relationship.  In EclipseLink, both OneToOne and
ManyToOne are implemented with the same class and therefore can be used to end
up with the same schema.

-Tom

cowwoc wrote:

> 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@...
>>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>>>>
>>>>>
>> _______________________________________________
>> eclipselink-users mailing list
>> eclipselink-users@...
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>
>>
>

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

[cowwoc]

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
>>> [e-mail]
>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>>
>>>
>>
>
_______________________________________________
eclipselink-users mailing list
[e-mail]
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

[cowwoc]

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

Thanks!
Gili


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
>>> [e-mail]
>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>>
>>>
>>
>
_______________________________________________
eclipselink-users mailing list
[e-mail]
https://dev.eclipse.org/mailman/listinfo/eclipselink-users