[Modeling-users] Summary objects and Proxy objects

[Ernesto R. <er...@si...>]

Don't take me too serious, I'm new to this list.

I agree that, especially for summaries, like statistics (counts, sums,
average, etc.) raw SQL access may be needed, I saw direct SQL calls in some
of existing products. But they return raw rows, i.e. an array. No middletier
functionality. On the otherhand, it may be interesting to encapsulate this
for later enhacenments.

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 extended,
telling the fetch machinery to return objects with some additional, user
requested attributes.

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:

objects=ec.fetchSummary(sourceEntityName="Book", what="count(*), avg(price),
  sum(toInvoiceLines.amount)", where="author.name like 'John*'",
  groupBy="author, genre", resultEntityName="BookSummary")

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 added
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.

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