Skip to main content
[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

Back to the top