GNCQuery (was Re: GncBusiness v. GNCSession)

[Linas Vepstas]

On Mon, Nov 26, 2001 at 10:13:01AM -0500, Derek Atkins was heard to remark:
> 
> So the real question is: If we change QueryTerms to use strings for
> type/member names, 

I think this is a good idea.

> can we guarantee that these strings will match the
> table names and column names in e.g. a SQL Backend 

That is up to the implementor of the backend.  There may be cases
where one intentionally wants a different structure in the backend.

> or e.g. a
> named-object lookup in the engine?  

I presume the answer is 'yes', if we expect anything to work at all.

> so that the Backend still doesn't need
> to know, a priori, about all extant data types.

Depends on the backend design.  Since you are hard-coding the C structs,
it also makes sense to hard-code the corresponding SQL structs.  And so,
by definition, the backend *does* know about data types.  

(This would still be true even if we auto-generated the majority of 
the backend code with compile-time m4 macros.  I'm not sure, haven't 
thought about it, but it may be possible to write 1 or 3 more m4 macros 
and autogenerate most of the business-object code.  Depends on how 
simple/complex the business objects are.)

If you don't want hard-coded SQL tables, but something dynamic,
run-time, well, then, this is an entirely new design.

> Also, as we want Query execution to be _fast_, are we sure that we
> want to use strings in the first place?

uhh, not sure, I don't know how Query actually traverses the data 
to find its matches.   Clearly, hashes with keys are faster than
walking a linked list, comparing strings ... On the other hand,
if the dataset is small, it doesn't matter.

--linas

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas@linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933