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