I've never found it onerous in Cayenne (or EOF) to apply a sort ordering if I care about the ordering of the returned results in a to-many. Maybe it is just because I understand that the List will be ordered, by default, in whatever sequence the database returned the records. If I need to order things differently, I can do it at the database level or provide cover methods to order by any attribute I choose in memory -- even after adding new records.
For the cases where an ordering is maintained in the database (by adding an integer column, for example), it is pretty trivial to add that column to order-by to your query. And one can always create the query/ordering in the Modeler to ensure the ordering is always applied (assuming a common query). I guess I just don't see this as a problem that is in dire need of being "solved". In the Hibernate training class I took, one of the complaints was all the different modeling options of the to-many relationship. The developers I know just wanted a list of objects. They just wanted to call getArtists() and have it work and be simple to set up. Something that could be iterated over and could be sorted later if they wanted, but the sorting was internal. I didn't mean for this to be a rant, but at some level you have to know where the ORM and DB demarcation line is. Cayenne (and other ORMs) can do a lot to minimize the work done, but I think the current approach is great for the overwhelming majority of use-cases. And it is trivial for a developer to add an integer-column to a table and maintain a position in it for apps that need it (like maintaining a queue). Cayenne works great for that, too, with minimal code having to be written to support it. mrg On Fri, Sep 26, 2008 at 3:52 PM, Andrus Adamchik <[EMAIL PROTECTED]> wrote: > That's a good point - we are trying to bridge the gap between OO and RDB > worlds in a best possible way. And I wish we could do a reasonable ordering > implementation (and without a join table). Otherwise the java.util.List > "contract" is indeed broken. > > Andrus
