FAQ
Are we going to track property changes of objects? E.g.:

// assume ordered on painting name
Painting p = ...
p.setName("A");
artist.addToPaintings(p);
p.setName("Z"); // should we reorder in this line?

I'd say no (although we can), and this probably means no to (1) and
(4). Although on commit we should probably detect that the ordering
property has changed, and reorder affected lists.

Andrus

On Mar 3, 2010, at 3:32 PM, Andrey Razumovsky (JIRA) wrote:

[ https://issues.apache.org/jira/browse/CAY-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andrey Razumovsky updated CAY-477:
----------------------------------

Attachment: 477-proto.patch

Here's prototype of how I see the issue.
Orderings can be added to objRelationship, and they are relative to
*target* entity (e.g. to Painting for "Artist.paintingArray"
relationship). For relationships with orderings, resolving returns
ordered list.

Some things to be done:
(1) Collection methods, like add() addAll() should keep the order.
(2) Map and Set support
For (1) and (2) we'll need to introduce different underlying
implementation of PersistentObject*
(3) Modeler support

(4) Not sure of this --> set() method of collections and changing
the object in ordered collection should somehow keep order. This is
unseen truth for maps but will be a pain for lists. Do we need this??
Support for preordered relationships
------------------------------------

Key: CAY-477
URL: https://issues.apache.org/jira/browse/CAY-477
Project: Cayenne
Issue Type: Task
Components: Core Library, Modeler
Affects Versions: Undefined future
Reporter: Andrus Adamchik
Fix For: Undefined future

Attachments: 477-proto.patch


This is already supported on the client (PersistentObjectList).
Need to either add support for it to ToManyList or migrate
DataContext to use PersistentObjectList. In any event Modeler
support is needed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Search Discussions

  • Andrus Adamchik at Mar 3, 2010 at 9:28 pm
    Also here is a reason why I don't find ordering of relationships
    particularly useful is that things like ordering are context dependent
    ("context" in a general sense)... The same mapping can be used by
    different UI frontends with different ordering requirements.

    Actually I even find callback mappings useless in my apps for that
    same reason. And it is even worse with orderings, as lists of objects
    may be reordered on the fly in the UI, initial ordering can be
    affected by user preferences, etc.

    So I feel like it looks good on a feature list, but will be barely
    usable in practice. Anybody can give real life examples to the opposite?

    Andrus

    On Mar 3, 2010, at 3:51 PM, Andrus Adamchik wrote:

    Are we going to track property changes of objects? E.g.:

    // assume ordered on painting name
    Painting p = ...
    p.setName("A");
    artist.addToPaintings(p);
    p.setName("Z"); // should we reorder in this line?

    I'd say no (although we can), and this probably means no to (1) and
    (4). Although on commit we should probably detect that the ordering
    property has changed, and reorder affected lists.

    Andrus

    On Mar 3, 2010, at 3:32 PM, Andrey Razumovsky (JIRA) wrote:

    [ https://issues.apache.org/jira/browse/CAY-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
    ]

    Andrey Razumovsky updated CAY-477:
    ----------------------------------

    Attachment: 477-proto.patch

    Here's prototype of how I see the issue.
    Orderings can be added to objRelationship, and they are relative to
    *target* entity (e.g. to Painting for "Artist.paintingArray"
    relationship). For relationships with orderings, resolving returns
    ordered list.

    Some things to be done:
    (1) Collection methods, like add() addAll() should keep the order.
    (2) Map and Set support
    For (1) and (2) we'll need to introduce different underlying
    implementation of PersistentObject*
    (3) Modeler support

    (4) Not sure of this --> set() method of collections and changing
    the object in ordered collection should somehow keep order. This is
    unseen truth for maps but will be a pain for lists. Do we need this??
    Support for preordered relationships
    ------------------------------------

    Key: CAY-477
    URL: https://issues.apache.org/jira/browse/CAY-477
    Project: Cayenne
    Issue Type: Task
    Components: Core Library, Modeler
    Affects Versions: Undefined future
    Reporter: Andrus Adamchik
    Fix For: Undefined future

    Attachments: 477-proto.patch


    This is already supported on the client (PersistentObjectList).
    Need to either add support for it to ToManyList or migrate
    DataContext to use PersistentObjectList. In any event Modeler
    support is needed.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.
  • Aristedes Maniatis at Mar 3, 2010 at 10:57 pm

    On 4/03/10 8:28 AM, Andrus Adamchik wrote:
    Also here is a reason why I don't find ordering of relationships
    particularly useful is that things like ordering are context dependent
    ("context" in a general sense)... The same mapping can be used by
    different UI frontends with different ordering requirements.
    Having a default ordering for ObjEntities defined in the model is what Rails does. Any time you fetch that entity, be it directly through a Query or via a relation, you get the results back with that ordering.

    Personally I don't see the point. Ordering in the database is very useful if you are paging the results. Or using a limit. But when following relations, neither of those things applies, so you may as well just do it in memory once you have the list returned.

    Perhaps a simplified notation might be useful though:

    artist.getPaintings(Comparator/Ordering)



    Ari

    --
    -------------------------->
    Aristedes Maniatis
    GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
  • Andrey Razumovsky at Mar 4, 2010 at 7:55 am
    The problem is that explicit query allows orderings, while indirect (via
    Artist.getPaintings()) does not (the same can be said about e.g. prefetches
    though). So, if I want some array to be sorted (which is quite often) I have
    to create queries for to-many orderings. Since I often use reflection-based
    invocations, I have to create new methods, like getOrderedPaintings(),
    moreover, bother about caching the data. IMO the feature is easy to
    implement (most is in the patch, actually) and worth it. Also note that
    we've seen several same wishes on the user list

    artist.getPaintings(Comparator/Ordering) is fine, but we can't generate that
    methods for every relationship, and more generic methods will lose things
    like Java Generics advantages.
    My vision is that this feature will be used for relationships that are
    ordered is same way [by default] in every context - e.g. I want people to be
    sorted by name everywhere.

    2010/3/4 Aristedes Maniatis <ari@maniatis.org>
    On 4/03/10 8:28 AM, Andrus Adamchik wrote:

    Also here is a reason why I don't find ordering of relationships
    particularly useful is that things like ordering are context dependent
    ("context" in a general sense)... The same mapping can be used by
    different UI frontends with different ordering requirements.
    Having a default ordering for ObjEntities defined in the model is what
    Rails does. Any time you fetch that entity, be it directly through a Query
    or via a relation, you get the results back with that ordering.

    Personally I don't see the point. Ordering in the database is very useful
    if you are paging the results. Or using a limit. But when following
    relations, neither of those things applies, so you may as well just do it in
    memory once you have the list returned.

    Perhaps a simplified notation might be useful though:

    artist.getPaintings(Comparator/Ordering)



    Ari

    --
    -------------------------->
    Aristedes Maniatis
    GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A


    --
    Andrey
  • Andrus Adamchik at Mar 4, 2010 at 11:46 am
    I agree with the query vs. relationship comparison. Unfortunately the
    mapping solution will correspond to a mapped query, vs. query created
    in the code.

    It is only easy to implement if we allow the list to go unordered on
    changes of its objects. Which I think is ok, as I mentioned earlier.

    Andrus
    On Mar 4, 2010, at 2:55 AM, Andrey Razumovsky wrote:

    The problem is that explicit query allows orderings, while indirect
    (via
    Artist.getPaintings()) does not (the same can be said about e.g.
    prefetches
    though). So, if I want some array to be sorted (which is quite
    often) I have
    to create queries for to-many orderings. Since I often use
    reflection-based
    invocations, I have to create new methods, like getOrderedPaintings(),
    moreover, bother about caching the data. IMO the feature is easy to
    implement (most is in the patch, actually) and worth it. Also note
    that
    we've seen several same wishes on the user list

    artist.getPaintings(Comparator/Ordering) is fine, but we can't
    generate that
    methods for every relationship, and more generic methods will lose
    things
    like Java Generics advantages.
    My vision is that this feature will be used for relationships that are
    ordered is same way [by default] in every context - e.g. I want
    people to be
    sorted by name everywhere.

    2010/3/4 Aristedes Maniatis <ari@maniatis.org>
    On 4/03/10 8:28 AM, Andrus Adamchik wrote:

    Also here is a reason why I don't find ordering of relationships
    particularly useful is that things like ordering are context
    dependent
    ("context" in a general sense)... The same mapping can be used by
    different UI frontends with different ordering requirements.
    Having a default ordering for ObjEntities defined in the model is
    what
    Rails does. Any time you fetch that entity, be it directly through
    a Query
    or via a relation, you get the results back with that ordering.

    Personally I don't see the point. Ordering in the database is very
    useful
    if you are paging the results. Or using a limit. But when following
    relations, neither of those things applies, so you may as well just
    do it in
    memory once you have the list returned.

    Perhaps a simplified notation might be useful though:

    artist.getPaintings(Comparator/Ordering)



    Ari

    --
    -------------------------->
    Aristedes Maniatis
    GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A


    --
    Andrey
  • Andrey Razumovsky at Mar 4, 2010 at 12:30 pm
    I think that will be enough for now.
    And what about EJBQL? Will it conflict with specification if we return
    relationships already preordered? (although I haven't yet thought of how to
    do it)

    2010/3/4 Andrus Adamchik <andrus@objectstyle.org>
    I agree with the query vs. relationship comparison. Unfortunately the
    mapping solution will correspond to a mapped query, vs. query created in the
    code.

    It is only easy to implement if we allow the list to go unordered on
    changes of its objects. Which I think is ok, as I mentioned earlier.

    Andrus


    On Mar 4, 2010, at 2:55 AM, Andrey Razumovsky wrote:

    The problem is that explicit query allows orderings, while indirect (via
    Artist.getPaintings()) does not (the same can be said about e.g.
    prefetches
    though). So, if I want some array to be sorted (which is quite often) I
    have
    to create queries for to-many orderings. Since I often use
    reflection-based
    invocations, I have to create new methods, like getOrderedPaintings(),
    moreover, bother about caching the data. IMO the feature is easy to
    implement (most is in the patch, actually) and worth it. Also note that
    we've seen several same wishes on the user list

    artist.getPaintings(Comparator/Ordering) is fine, but we can't generate
    that
    methods for every relationship, and more generic methods will lose things
    like Java Generics advantages.
    My vision is that this feature will be used for relationships that are
    ordered is same way [by default] in every context - e.g. I want people to
    be
    sorted by name everywhere.

    2010/3/4 Aristedes Maniatis <ari@maniatis.org>
    On 4/03/10 8:28 AM, Andrus Adamchik wrote:

    Also here is a reason why I don't find ordering of relationships
    particularly useful is that things like ordering are context dependent
    ("context" in a general sense)... The same mapping can be used by
    different UI frontends with different ordering requirements.
    Having a default ordering for ObjEntities defined in the model is what
    Rails does. Any time you fetch that entity, be it directly through a
    Query
    or via a relation, you get the results back with that ordering.

    Personally I don't see the point. Ordering in the database is very useful
    if you are paging the results. Or using a limit. But when following
    relations, neither of those things applies, so you may as well just do it
    in
    memory once you have the list returned.

    Perhaps a simplified notation might be useful though:

    artist.getPaintings(Comparator/Ordering)



    Ari

    --
    -------------------------->
    Aristedes Maniatis
    GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A

    --
    Andrey

    --
    Andrey
  • Andrus Adamchik at Mar 4, 2010 at 12:57 pm
    I don't think it will conflict with EJBQL in any way.
    On Mar 4, 2010, at 7:29 AM, Andrey Razumovsky wrote:

    I think that will be enough for now.
    And what about EJBQL? Will it conflict with specification if we return
    relationships already preordered? (although I haven't yet thought of
    how to
    do it)

    2010/3/4 Andrus Adamchik <andrus@objectstyle.org>
    I agree with the query vs. relationship comparison. Unfortunately the
    mapping solution will correspond to a mapped query, vs. query
    created in the
    code.

    It is only easy to implement if we allow the list to go unordered on
    changes of its objects. Which I think is ok, as I mentioned earlier.

    Andrus


    On Mar 4, 2010, at 2:55 AM, Andrey Razumovsky wrote:

    The problem is that explicit query allows orderings, while indirect
    (via
    Artist.getPaintings()) does not (the same can be said about e.g.
    prefetches
    though). So, if I want some array to be sorted (which is quite
    often) I
    have
    to create queries for to-many orderings. Since I often use
    reflection-based
    invocations, I have to create new methods, like
    getOrderedPaintings(),
    moreover, bother about caching the data. IMO the feature is easy to
    implement (most is in the patch, actually) and worth it. Also note
    that
    we've seen several same wishes on the user list

    artist.getPaintings(Comparator/Ordering) is fine, but we can't
    generate
    that
    methods for every relationship, and more generic methods will lose
    things
    like Java Generics advantages.
    My vision is that this feature will be used for relationships that
    are
    ordered is same way [by default] in every context - e.g. I want
    people to
    be
    sorted by name everywhere.

    2010/3/4 Aristedes Maniatis <ari@maniatis.org>
    On 4/03/10 8:28 AM, Andrus Adamchik wrote:

    Also here is a reason why I don't find ordering of relationships
    particularly useful is that things like ordering are context
    dependent
    ("context" in a general sense)... The same mapping can be used by
    different UI frontends with different ordering requirements.
    Having a default ordering for ObjEntities defined in the model is
    what
    Rails does. Any time you fetch that entity, be it directly
    through a
    Query
    or via a relation, you get the results back with that ordering.

    Personally I don't see the point. Ordering in the database is
    very useful
    if you are paging the results. Or using a limit. But when following
    relations, neither of those things applies, so you may as well
    just do it
    in
    memory once you have the list returned.

    Perhaps a simplified notation might be useful though:

    artist.getPaintings(Comparator/Ordering)



    Ari

    --
    -------------------------->
    Aristedes Maniatis
    GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A

    --
    Andrey

    --
    Andrey
  • Kevin Menard at Mar 13, 2010 at 6:44 pm

    On Thu, Mar 4, 2010 at 6:45 AM, Andrus Adamchik wrote:

    It is only easy to implement if we allow the list to go unordered on changes
    of its objects. Which I think is ok, as I mentioned earlier.
    I think this is reasonable behavior. Once you have the list, it's
    your responsibility to make sure you place elements in the correct
    order. Having the list re-sort on insertion would break list
    semantics.

    --
    Kevin
  • Kevin Menard at Mar 13, 2010 at 6:41 pm

    On Wed, Mar 3, 2010 at 5:57 PM, Aristedes Maniatis wrote:

    Having a default ordering for ObjEntities defined in the model is what Rails
    does. Any time you fetch that entity, be it directly through a Query or via
    a relation, you get the results back with that ordering.

    Personally I don't see the point. Ordering in the database is very useful if
    you are paging the results. Or using a limit. But when following relations,
    neither of those things applies, so you may as well just do it in memory
    once you have the list returned.
    I have to disagree. The way Rails does it handles the most common
    cases extraordinarily well. Many objects have some sort of natural
    creation order, whether that be through monotonically increasing IDs
    or timestamps. In any event, it's quite handy to have:

    - "Order.all" return all orders in reverse chronological order
    - "customer.orders.all" return all orders in reverse chronological order

    So forth and so on.

    Certainly this could be done in memory. It just means I'm now adding
    template code in all my generated class files that basically do the
    same thing and that the framework could handle very easily for me.
    I'd really rather have that handled in the data map. I'd event settle
    for a class-level annotation for specifying a default sort order.
    But, the non-deterministic default return order is usually a bad
    default unless I'm really just looking for collection behavior.

    --
    Kevin

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedMar 3, '10 at 8:51p
activeMar 13, '10 at 6:44p
posts9
users4
websitecayenne.apache.org

People

Translate

site design / logo © 2021 Grokbase