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
But then users would have to code checking for nulls during iteration for a case that should never happen.  Most users would not expect this requirement and would not code for it resulting in unrecoverable exceptions on read.
Better for us to ignore the corruption on read and fix the indexes on write.  Raising warnings if we do discover corruption.
--Gordon

Michael Keith wrote: 
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