RE: Idea for index/limit support

From: Gentry, Michael \(Contractor\) ("Gentry,)
Date: Tue Sep 06 2005 - 10:30:30 EDT

  • Next message: Gentry, Michael \(Contractor\): "Cayenne 1.2 + PostgreSQL"

    I really can't imagine my to-many faults not returning everything in the
    relationship. I certainly wouldn't want it to only fault in what I try
    to read (that would require far too many SELECTs and hurt performance).
    And it's probably too arbitrary to pick N records for it to read in at a
    time.

    Given your example, it still seems like you are still having your BLOB
    data inside a table with other data instead of isolated. So, when you
    fault your to-many relationship, you are getting all of the BLOB data (N
    rows) in addition to the other attributes. This is almost always going
    to be a lose situation using ORM.

    All that being said, perhaps a paginated query could help you out?

    http://www.objectstyle.org/cayenne/userguide/perform/paged-queries.html

    /dev/mrg

    -----Original Message-----
    From: Gili [mailto:cowwo..bs.darktech.org]
    Sent: Monday, September 05, 2005 3:29 AM
    To: cayenne-deve..bjectstyle.org
    Subject: Idea for index/limit support

            Aside from the obvious idea that queries should be able to set
    index/limit, I'm thinking we should modify the behavior of relationship
    getting methods. Currently they return a List from xxxArray
    relationships. I'm thinking we should implement the List interface, and
    provide special index/limit/fetchSize methods in our implementation.
    This way old code continues working as is and new code that wishes to
    optimize performance does something like this:

            List images = dataObject.getImageArray();
            CayenneList typedImages = (CayenneList) images;

            // (optional) configure List before using it
            typedImages.setFetchSize(10);
            typedImages.setMinIndex(15);
            typedImages.setMaxIndex(30);

            // use list like we always did
            typedImages.get(20);

            now... min/max indexes are hints to the List implementation as
    to what
    index/limit values to issue the query with. If a user tries to get() an
    index outside this range we will issue a second query but this is
    unlikely to happen. The typical usage scenerio would be if the above had

    100,000 rows in the result we'd see a noticable performance benefit of
    only retrieving 15 rows (index 15 - 30 inclusive). And best of all, this

    change is completely backwards compatible with older releases. What do
    you think?

    Gili 

    -- 
http://www.desktopbeautifier.com/

    This archive was generated by hypermail 2.0.0 : Tue Sep 06 2005 - 10:30:35 EDT