Query Integration: access to Query Internals?

[Derek Atkins]

I decided that so much depends on core types that they should just be
hard-coded.  How often does one define a new core type?  (Where a core
type is defined as things like String, Numeric, Timespec, GUID,
Double, Boolean, etc.).  So, I just decided to not make that interface
pluggable.

A backend can still plug in a new composite type built from the core
engine types, but it can't provide a new core data type.

The interfaces are still there if we decide to change this -- just
need to make them non-static and publish the interface in the .h
(i.e., I didn't change the architecture).  But I figured that this
would be an easier way of doing it in the short run, and in the long
run I don't see many new types being added.

-derek

linas@linas.org (Linas Vepstas) writes:

> Hi,
> 
> 
> On Sat, Jun 01, 2002 at 12:46:17AM -0400, Derek Atkins was heard to remark:
> > Indeed, a new gnc-module could theoretically define a new data-type
> > and add it to the query engine.  It just registers the type and it is
> > automatically plugged into the system.  If that happens, how can we
> > easily get get the various backends to work if they need to know about
> > the internals of that type?
> > 
> > I see a few potential approaches to solve this problem.
> > 
> > 2) Provide a new registry, where each data type defines the
> >    appropriate conversions of each backend.  This would basically mean
> >    that for each backend you would need to define an interface and
> >    implement the code that converts a "PredData_t" to whatever the
> >    backend requires.  If you add a new backend, you need to provide a
> >    new set of converters for each existing data-type; if you add a new
> >    data-type you need to provide a new set of converters for each
> >    backend.
> > 
> > 3) Provide some "common export format" that the Query can be
> >    transposed into, and require all backends to convert between this
> >    "common export format" and its internal format.  For example, we
> >    could define a standard "scheme" format for a query and require all
> >    backends to be able to convert from this common scheme format to
> >    their internal format.  Alternatively we could define this format
> >    to be "SQL" and require all backends to be able to parse (or
> >    re-parse) the SQL.
> 
> I'm not sure I understand the difference between 2 and 3.  After all,
> with proposal 3, a back end still needs to know how to store and load
> the newly defined type, (and, for sql, how to build queries with it).
> So I don't see how 3 is better or avoids some of the work needed for 2.
> 
> 
> > At some level, the backends need to be all-knowing -- they do sort of
> > need to know how to handle all the basic data types.  On another
> > level, however, I'd like even the backends to be "pluggable".  As it
> > stands now a gnc-module can add objects to the XML backend.  Indeed,
> > that's how the business objects are implemented!  I'd like to add this
> > same pluggable functionality to, say, the Postgres backend.
> 
> Sure.  
> (I'm not sure why I'm replying to this email right now; I'm tired and my
> head is foggy... but you said you wanted my reply so...)
> 
> > I guess the question is whether it's reasonable to assume that, say,
> > the backends can convert a standard query framework to an internal
> > version.  For example, presume something like:
> > 
> > '(<gnc:query>
> >   Split ; <- what we're searching for
> >   ;; List of "OR" Lists of AND terms:
> >   ((((trans description) #f (string compare-equal string-match-normal #f
> >                              "foo"))
> >     ((account code) #t (string compare-neq string-match-caseinsentive #f
> >                         "300")))
> >    (((value) #f (numeric compare-gt amt-sign-match-credit (10000 . 100)))))
> >   ; Sort order...
> >   ; max results
> >   ...)
> 
> Yes, the above can be converted to SQL. It would be somewhat tedious
> and I wouldn't volunteer to write that code.  
>  But this example also doesn't illustrate a new data type.  
> Or the plugin that would handle it.
> 
>     (((punt) #f (ball compare-is-goal check-yardage ("20" . "down")))))
> 
> The parser needs to know that 'punt' is a newly defined type, call the
> plugin for it, which needs return the string
> 
> gncFootball.yardage>=20 AND gncDown=4
> 
> so that it can be inserted into the xxx part of a standard query:
> 
> SELECT * FROM gncSplit WHERE gncTransaction.description='foo' AND
> gncAccount.doe='300' AND gncSplit.value=10000 AND xxxxxx
> 
> I mean I guess this is obvious, but...
> 
> > (My other alternative is to ignore the problem and break the SQL
> > Backend, but that would be rude ;)
> 
> Acckk!
> Surely not!  but I guess you can't convert the new query into the 
> old-style query objects that the backend currently uses?
> 
> --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

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