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

In fact we could run this SELECT COUNT(*) ... sql just once - marking in the cache key the fact that the order has been verified. If the object serialized and its cache key in the new session doesn't have db verified check mark, then we just run the SELECT COUNT (*) one more time. ----- Original Message ----- From: "Andrei Ilitchev" <andrei.ilitchev@xxxxxxxxxx> To: "Dev mailing list for Eclipse Persistence Services" <eclipselink-dev@xxxxxxxxxxx>
Sent: Tuesday, March 10, 2009 2:45 PM
Subject: Re: [eclipselink-dev] Minutes: Functional Discussion - Ordered Lists


Yes, if there's an INSERT (as opposed to DELETE and UPDATE (UPDATE may happen in DirectCollection case)) the trick doesn't work (because there's no WHEREE clause in insert).
In that case need to run
SELECT COUNT(*) FROM my_table WHERE (PROJ_ID = projIdToAdd AND (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 2:24 PM
Subject: 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
_______________________________________________
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