[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] @ManyToMany relationship for a List?
|
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
