Re: [Modeling-users] Summary objects and Proxy objects

[Sebastien B. <sbi...@us...>]

"Ernesto Revilla" <er...@si...> wrote:
> Don't take me too serious, I'm new to this list.
>=20
> I agree that, especially for summaries, like statistics (counts, sums,
> average, etc.) raw SQL access may be needed, I saw direct SQL calls in so=
me
> of existing products. But they return raw rows, i.e. an array. No middlet=
ier
> functionality. On the otherhand, it may be interesting to encapsulate this
> for later enhacenments.
>=20
> In one of the papers I studied on this theme
> (http://www.ambysoft.com/persistenceLayer.pdf, pg 7, point 8.) I saw the =
use
> of proxy objects which are light weight objects with the most basic
> attributes (some user-key, name and few more). This idea could be extende=
d,
> telling the fetch machinery to return objects with some additional, user
> requested attributes.

The idea of proxies is quite interesting and notably pretty
straightforward to implement. Suppose the ability to fetch raw rows is
implemented, the common idiom would be (not speaking about the fetch()
shortcut) something like this:

  >>> qual=3DqualifierWithQualifierFormat('title ilike "%t%"')
  >>> fs=3DFetchSpecification('Book', qual)
  >>> fs.setFetchesRawRows(true)
  >>> fs.setRawRowsKeyPath('id', 'title', 'author.lastName')
  >>> rows=3Dec.objectsWithFetchSpecification(fs)
  >>> print rows
  ({'id': 1, 'title': 'Gargantua', 'author_lastName': 'Rabelais'},
   {'id': 2, 'title': 'Bouge ton pied...', 'author_lastName': 'Dard'},
   {'id': 4, 'title': "T'assieds pas...", 'author_lastName': 'Dard'},
  )

  (note: I consider that dicts are better than arrays as a result set)

  Then it simply a matter of declaring:=20
  >>> class GenericProxy: pass
  after which the creation and initialization of the proxies is just:
  >>> proxies=3D[GenericProxy() for i in range(len(rows))]
  >>> [proxies[i].__dict__.update(rows[i]) for i in range(len(rows))]

  That's all!

  And that's a really nice idea.

> On the other hand, we could have summary objects, because it's very usual=
 to
> get sums, counts and averages. The idea is that the resultset would be an
> encapsulated a collection of summary objects:
>=20
> objects=3Dec.fetchSummary(sourceEntityName=3D"Book", what=3D"count(*), av=
g(price),
>   sum(toInvoiceLines.amount)", where=3D"author.name like 'John*'",
>   groupBy=3D"author, genre", resultEntityName=3D"BookSummary")
>=20
> This may seem to be a  SQL  (OQL is very near to), but it has advantages
> over SQL:
> * the dotted notation is allowed (get away from ugly inner joins).
> * it would process inheritance trees
> * don't have to repeat the grouping fields in select clause, they are add=
ed
> automatically
> The only purpose of the entityName is to give an 'entry entity' which the
> attributes are related to. The result could be just an instance of
> 'SummaryObject', or perhaps an instance of a special BookSummary which
> encapsulates special behaviour.

* You make me realize that my previous answer to Mario saying ''you'll
  have to be able to distinguish between table alias t1 and table alias
  t2 when declaring attribute author.age and that's a problem bla bla
  bla'' was stupid: the dotted notation obviously solves this naturally
  (the distinction between author.age and author.pygmalion.age is
  clear).

* You're partially answering to the question of real-life examples
  --although I still need to familiarize myself with 'group by' and
  'having' statements.

* This brings a different light to what Mario formerly proposed
  (different api but the very same idea as far as I can see) --just
  because we here use a different method (fetchSummmary instead of
  fetch); sorry, sometimes I can't see the forest for the trees because
  of such details :|

  Now that the concept (summaries) is clearer to me I'm beginning to see
  the ideas behind. And I guess I'm not far from thinking that, okay,
  fetchSummary() does contain raw sql pieces, but that it's maybe not
  such a big deal if this covers common needs.

* could this be made clearer: despite the fact that I cannot really see
  its implication for the moment being, I have the feeling that 'group
  by' and multiple fetches (walking through the inheritance tree) is not
  only a matter of getting the results and assembling them one after the
  other, is it?

> Should the result be a flat list or a tree-like list or dictionary?

  I cannot answer that: as I said I'm not familiar enough with this kind
  of queries to see what form would be the most accurate, or whether it
  could depend on the query itself. I'd need different examples and your
  opinion here.

    BTW I suggest that we do not consider this as an element of the
    current API change proposal, rather as a new feature request.


  Last, you wrote:
> On the other hand, we could have summary objects, because it's very
> usual to get sums, counts and averages.

I'd like to hear more about those usual cases, if you could give some
examples that would help --help me, at least ;) since my personal
approach to that kind of things would be e.g. to treat the raw rows
on the python side rather than to ask the rdbms to do the job.

-- S=E9bastien.