Re: high-volume offline processing using cayenne?

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Tue Feb 25 2003 - 10:28:27 EST

  • Next message: Andrus Adamchik: "Re: No need that IteratedQuery blocks the connection"

    Hi Arndt,

    see my comments below.

    > meanwhile I tried to batch-commit feature in
    > the current CVS - seems to work as expected (good job!).
    >
    > (It took me some time to figure out
    > that I have to use "commit" instead
    > of "commitChanges" in order to make use
    > of it :-) )

    Yes, this is temporary. Once we fully integrate batch commits, there will
    be only one method - "commitChanges"

    > SELECT ... FROM painting t0 where t0.gallery_id = ?
    >
    > the corresponding query for a set of objects simulanously:
    >
    > SELECT ... FROM painting t0 where t0.gallery_id IN ( ?, ?, ?, ...)
    >
    > That's a big boost (at least on oracle), at least in the
    > case where "ToMany" usually means "to-very-few" (1,2,3,...),
    > as in ou case.
    >
    > I've no clear idea how such a feature could be
    > integrated in the API, one possibility would be
    > to have a method on DataContext:
    >
    > resolveRelationsForObjects( List dataObjects, String relName );
    >
    > to trigger the relation-resolving for a list of
    > objects of the same type.
    >
    > (I understand that this is nothing for your 1.0 version,
    > but maybe you can give me a hint how to add it as
    > a quick&dirty patch...)

    This is such an important feature that we couldn't overlook it :-). It is
    called "prefetching":

    http://objectstyle.org/cayenne/api/cayenne/org/objectstyle/cayenne/query/SelectQuery.html#addPrefetch(java.lang.String)

    I haven't advertised it much (and haven't mentioned it in the user guide)
    since there are a few serious bugs in implementation. We will work on
    fixing them either now or while in Beta.

    > > I really like (b) - the idea of cleanly separating
    > > "configuration" immutable objects from the objects
    > > being modified, but still maintaining the same object
    > > graph. Unfortunately this is not planned for 1.0 and
    > > will probably be included in the later releases.
    >
    > I agree that having 2 dedicated "levels" of data-contexts
    > (shared-config/worker-context) would be sufficient, but
    > I cannot see that this is really simpler than a real
    > recursive solution of nested data-contexts. The api
    > would simply be:
    >
    > DataContext subContext = ctxt.createSubContext();
    > ...
    > subContext .query(...);
    > ...
    > subContext .commit(...);
    > subContext = null;
    >
    > I've no real idea of how difficult that is to implement,
    > but I can try to dig into it...

    Let us know!

    Andrus

    This archive was generated by hypermail 2.0.0 : Tue Feb 25 2003 - 10:28:28 EST