[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipselink-dev] Minutes: Functional Discussion - Ordered Lists
|
It does not resolve the following...
given a table that looks like:
proj1_id | 0
proj2_id | 1
proj3_id | 2
proj4_id | 3
proj5_id | 10
the following all fail to detect the corruption and refreshing the
collection post add results in a collection that is out of order.
emp.getProjects().add(emp.getProjects().remove(0));
and/or
emp.getProjects().add(emp.getProjects().remove(1));
and/or
emp.getProjects().add(emp.getProjects().remove(2));
and/or
emp.getProjects().add(emp.getProjects().remove(3));
or
emp.getProjects().add(new Project());
etc.
--Gordon
Andrei Ilitchev wrote:
1..3.2.1 resolves 100% db corruption in case object is either removed
or its position altered.
The only case left is adding a new object - in this case we can run
an sql verifying that the db is ok, something like:
SELECT COUNT(*) FROM my_table WHERE (ORDER_INDEX = null OR ORDER_INDEX
< 0 OR ORDER_INDEX >= size)
----- Original Message ----- From: "Gordon Yorke"
<gordon.yorke@xxxxxxxxxx>
To: "Dev mailing list for Eclipse Persistence Services"
<eclipselink-dev@xxxxxxxxxxx>
Sent: Tuesday, March 10, 2009 1:55 PM
Subject: Re: [eclipselink-dev] Minutes: Functional Discussion -
Ordered Lists
Peter,
1.3.2.1 - this only resolves corruption in certain cases. I thought
we were going to attempt to record that the list was corrupt upon
reading in cases that we could?
--Gordon
Peter Krogh wrote:
Minutes:
Open Issues:
1.3.2.1 Non Contiguous Index values Resolution:
include the expected index in the where clause. If the update
fails, assume that the list is non-contiguous. Re-index the list.
1.3.2.2 Indexing new elements in un-instantiated IndirectLists
Resolution: Don't support un-instantiated IndirectLists with Ordered
List.
1.3.2.3 OrderColumn table Resolution: One to Many: support
OrderColumn on any Target table
Join Table: only support OrderColumn on Join Table
Throw an exception if any other table is specified.
1.3.2.4 Duplicate support Resolution: Looking into Duplicates now.
Will determine impact of supporting Duplicates as further
prototyping is done.
Duplicates with Private Owned an issue.
1.3.2.5 "Two-way" order support Employee.projects and
Projects.employees; say add ORDER_EMP and ORDER_PROJ fields to the
join table? Resolution: We are not at this time supporting a
different ordering on 2 mappings sharing the same join table (one
being read only).
1.3.2.6 Constraints in the DB - is that possible? Resolution:
Log a Doc Bug: can't make index column part of the PK.
1.3.2.7 Target optimistic locking
Resolution:
Only uni-directional, use the flags that already exist on the
Mapping.
Move the flags to OneToMany.
-----Original Message-----
From: Peter Krogh Sent: Monday, March 09, 2009 9:11 AM
To: eclipselink-dev@xxxxxxxxxxx
Subject: RE: Functional Discussion - Ordered Lists
We will use the call in information described here:
http://wiki.eclipse.org/EclipseLink/Development/DevMeetings
-----Original Message-----
From: Peter Krogh Sent: Thursday, March 05, 2009 3:39 PM
To: eclipselink-dev@xxxxxxxxxxx
Subject: Functional Discussion - Ordered Lists
I propose that we have a dicussion on the functional direction of
Ordered Lists.
A doc with open issues is here:
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/ordered_lists
Monday: Mar 9th 2009
Time: 1:00pm est
Required: Doug Clarke, Shaun Smith, Andrei Ilitchev, Gordon Yorke,
Mike Keith
Peter Krogh
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev