On 27/12/2007, at 9:18 PM, Andrus Adamchik wrote:
> Here is how I see the main design abstractions of context and query:
>
> * "query" is a _descriptor_ of an arbitrary database operation, with
> no knowledge of the runtime (EOF explicitly calls it
> EOFetchSpecification, "specification" == "descriptor"). While we
> compromised on that in the backend by introducing query callback
> methods ('createSQLAction', 'route'), those methods are extension
> points that are not visible to the user.
>
> * "context" is the environment facade object that executes queries.
>
> I don't see how we will benefit by turning this around?
OK. I guess I perceived the purposes of these classes differently:
what does executing a query which returns datarows have to do with
manipulating the context (that is it is a function of the context)?
But philosophical debates are really not the important point here.
Whether the query is performed on the context or on the query, the
problems to solve are:
* how does the query find out which persistent class it is operating
on (the root class)
* how does it know which type of data to return (datarows, map, list
of persistent objects, something else we invent in the future)
So let's not get sidetracked by my red herring of which class the
performQuery function lives in.[1] Let's pretend I didn't raise that
issue.
Ari
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
This archive was generated by hypermail 2.0.0 : Thu Dec 27 2007 - 06:14:14 EST