GncBusiness v. GNCSession

[Derek Atkins]

linas@linas.org (Linas Vepstas) writes:

> > Honestly I think we need to look at it a bit more carefully.  I think
> > I see where this is heading, but I'm going to have to study the Query
> > object a bit more before I truly think that I've got it.  Also,
> > another thing -- currently the Query always returns a GList* of
> > Splits, no?  
> 
> two routines returns splits, the third returns transactions.
> 
> > How are we going to change that to query other types of
> > data?
> 
> Part a) represent the query
> Part b) execute the query
> 
> The above is a proposal only for part a.

Which implies that we would need to add new execution paths.
That makes sense.

> > If we could always assume a SQL backend life would be much easier :)
> 
> No it wouldn't, for the six reasons I described in the previous note.
>
> Really, Derek, just a week ago, our positions were reversed.  I was
> suggesting that you hard-code something, and you insisted on
> extensibility.  And now, you are just the opposite ...

Not at all.  I still believe that extensibility is the right thing.  I
always have.  I was just commenting that if I could assume that all
backends can execute a SQL query then I can, as I've shown you how in
previous mail, build up the SQL Query String piecemeal in an extremely
extensible way.

My frustration is that how a query is executed for the XML/File
backend is completely different than how it is executed for the
postgres backend.  In the Postgres backend you convert the GncQuery
into a char* and then pass the char* into the Postgres engine.

In other words, part 'b', for the Postgres backend, can be broken
up into two parts:

	b1) parse the GNCQuery into a char*
	b2) pass the char* into the Postgres engine

Part b1 can be done in a distributed manner.  You don't necessarily
need to the GNCQuery parsing routine to exist in one body of code; you
can register new GNCQuery parsing routines at run-time.  The 'b1'
process will call into the registered functions to convert, e.g. the
GncInvoice QueryTerm into a char* that can be part of the postgres
query.

Unfortunately this process doesn't work in the XML/File Backend, which
is why I stated SQL would be easier.

> > That notwithstanding, what I think we want is the ability to have
> > nested ANDs and ORs where each QueryTerm has an object-type, and then
> > an object-specific term and value.
> 
> Yes.  Each object has a number of fileds, and you have to be able to
> specify ==, >, <, !=, etc on each field.
> 
> > I think I still need to think on this a bit more, in particular how to
> > extend the Query to return, e.g., a GList* of GncCustomer or a GList*
> > of GncInvoice, or...
> 
> yes.

Ok.

> --linas

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available