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
Alternative approach would be to read objects using ORDER BY order_column - but without actually reading in the falues of ordered field. That way always produces a list of two objects no matter what are the actual values of order field in the db. The order values in the db may be corrected when Eclipselink needs to update some of them. 
Example:
 {0 id0, 2 id2} in the db is read into {0 id0, 1 id2} list.
 Now transpose the list members: {0 id2, 1 id0}
When writing out the changes Eclipselink may verify whether the original order values were contiguous - and re-write all members with the contiguous value if not: UPDATE my_table SET order = 0 WHERE (id = id2 and order = 1) - this sql doesn't update any rows, indicating that the expected order =1 is not in the db; 
 Eclipselink re-orders the whole list:
   UPDATE  my_table SET order_column = 0 WHERE id = id2
   UPDATE  my_table SET order_column = 1 WHERE id = id0
----- Original Message ----- From: "Michael Keith" <MICHAEL.KEITH@xxxxxxxxxx> To: "Dev mailing list for Eclipse Persistence Services" <eclipselink-dev@xxxxxxxxxxx> 
Sent: Monday, March 09, 2009 5:05 PM
Subject: RE: [eclipselink-dev] Minutes: Functional Discussion - Ordered Lists 



That's what I would expect.


-----Original Message-----
From: Andrei Ilitchev
Sent: Monday, March 09, 2009 5:03 PM
To: Dev mailing list for Eclipse Persistence Services
Subject: Re: [eclipselink-dev] Minutes: Functional Discussion
- Ordered
Lists


Are you saying that two rows in the db with order values 0
and 2 should be
read as a list of 3 elements with null in the middle?
----- Original Message ----- From: "Michael Keith" <MICHAEL.KEITH@xxxxxxxxxx> 
To: "Dev mailing list for Eclipse Persistence Services"
<eclipselink-dev@xxxxxxxxxxx>
Sent: Monday, March 09, 2009 4:31 PM
Subject: RE: [eclipselink-dev] Minutes: Functional Discussion
- Ordered
Lists


Sorry, couldn't be at the meeting.

One case that I wanted to mention is the null value case.
For example:

List l = new ArrayList();
l.add(obj1);
l.add(obj2);
l.add(obj3);
...
l.set(1, null);

causes the order of obj1 to be 0 abd obj3 to be 2.
When re-read the list would be (obj1, null, obj3).

More comments below...

> -----Original Message-----
> From: Peter Krogh
> Sent: Monday, March 09, 2009 2:45 PM
> To: eclipselink-dev@xxxxxxxxxxx
> Subject: [eclipselink-dev] Minutes: Functional Discussion - Ordered
> Lists
>
>
> 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.

Could it also be a list manipulation collision and be the
equivalent of an optimistic lock exception?

> 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.

Okay.

> 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.

Spec does not enumerate the duplicates 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).

Spec is silent on having ordered Lists on both sides of an m-m.
Might be worth mentioning in the spec, though.

> 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

Back to the top