Re: sort attribute for referenced relation

From: Holger Hoffstätte (holge..izards.de)
Date: Tue Dec 03 2002 - 19:59:32 EST

  • Next message: martin ruff: "org.objectstyle.cayenne.CayenneRuntimeException: Some parts of PK are missing in snapshot"

    Dirk Olmes wrote:
    > Well, I just did a quick check and adding directly to the ToManyList
    > works, too (well, at least for my simple test case).

    Btw, I thought about this some more and even though I was opposed to
    directly modifying the relationship List at first, I have come to the
    conclusion that it really would be nice to have and much simpler in
    everyday uses.

    > > 2. Now that I wrote (1), I almost regret about it :-). Your idea of
    > > modifying to-many relationships via simple "add/remove" list API is very
    > > appealing... So, why don't we concentrate on making add/remove work via
    > > ToManyList (clean behind the scenes way).
    >
    > YES!

    You mean you volunteer? :->

    [no sorting on the object level]

    > don't have sorted collections. What I would normally do is to override
    > the get accessor method for the relationship and sort the List before
    > returning it. I could even cache that sorted List and invalidate that
    > cache when adding/removing from it. This would give me sorted
    > relationships minus the ability to directly modify the List and have
    > Cayenne do the right thing(tm).

    This is the way EOF can be hacked into sorted shape, yes. I'd be curious
    how TopLink could be forced to do this? Can it use any custom collection
    class? (Andrus?)

    > What about the following approach: In order to keep the ToManyList
    > always sorted we'd document that the add methods will not guarantee that
    > you'll get the same object after inserting at a certain index. This is

    This is what I finally arrived at with my implementation. There is NO
    other way.

    > I even found the following for the add(index, object) method:
    >
    > "Inserts the specified element at the specified position in this list
    > (optional operation)."
    > What does the "optional operation" apply to? Insert the object? Does

    'Might explode or not. We don't know.'

    In reality it's a useless statement since AbstractList's ListIterator
    relies on this method, so it's anything but 'optional'. They _could_ have
    used marker interfaces for mutability, optional operations and a lot more
    things, but I guess that was just too complicated for them.

    -h



    This archive was generated by hypermail 2.0.0 : Tue Dec 03 2002 - 23:24:29 EST