DB API

[Christopher Browne]

On 18 Dec 2000 13:20:17 EST, the world broke into rejoicing as
Derek Atkins <warlord@MIT.EDU>  said:
> grib@gnumatic.com (Bill Gribble) writes:
> 
> > On Mon, Dec 18, 2000 at 01:00:56PM -0500, Derek Atkins wrote:
> > > This is a reasonable approach, although I think we still want (need?)
> > > to be flexible enough to make some rather robust queries.  For
> > > example, I can certainly see where you might want to search for
> > > transactions in an account between specific dates, or certain reports
> > > might want to make certain more extensive queries.  
> > 
> > I think at the minimum any database backend should support the
> > complete gnucash query API as it exists now (src/engine/Query.c).
> > 
> > That's not terribly complicated: just AND-OR trees of simple terms
> > where each term consists of one of about 6-8 different predicates and
> > a handful of parameters.  Value comparisons, date range comparisons,
> > string comparisons, etc.  I would expect most of the predicates to be
> > either directly supported or simple to code in any real database, with
> > the possible exception of regular expression matching in strings, and
> > the and-or structure could be trivially traversed (I think) to create
> > a single SQL query statement.
> > 
> > Bill Gribble
> 
> Ahh, wonderful..  The RPC would only need to implement the equivalent
> of 'xaccQueryGetSplits()' :) So, we get our batching for free,
> provided that the UI doesn't call GetSplits() on every change to the
> Query object.  That makes life really simple.
> 
> Wonderful!

CORBA would definitely support this sort of thing; probably the
preferable approach would be to pass around sets of information as
"sequences," which are usually represented as arrays of whatever
structure is being referenced.

If we have a transaction:
struct transaction {
  string GUID;
  string description;
  date TxnDate;
  .... and more fields ... 
}; 
it is perfectly natural to represent:
typedef sequence<transaction> TransactionList;

The notion that an RPC scheme needs to be inefficient because
transferring 2000 transactions requires the overhead of 8000 
back-and-forth network transfers is Just Silly; a reasonable
design should certainly be able to transfer a bunch of data at
once.

The thing that makes life a bit more complicated is that we
might want to have limits on how many of a [thing] should be grouped
together...
--
(concatenate 'string "cbbrowne" "@ntlug.org")
<http://www.hex.net/~cbbrowne/>
Rules of the Evil Overlord #203.  "I will not employ an evil wizard if
he has a sleazy mustache." <http://www.eviloverlord.com/>