Re-working GNCId: removing GNCIdType enum
Linas Vepstas
linas@linas.org
Sun, 25 Nov 2001 15:08:20 -0600
On Sat, Nov 24, 2001 at 04:53:08PM -0800, Dave Peticolas was heard to remark:
> On Sat, 2001-11-24 at 16:19, Derek Atkins wrote:
> > backend/postgres/events.c
>
> This one is complicated, we would have to make a general
> mechanism for detection events for the other, newer types.
> This would probably need to be part of the backend extension
> mechanism.
>
>
> > backend/postgres/gncquery.c
>
> Here I'm not sure using other types besided
> accounts, transactions, and splits would
> make sense, unless guid Queries are extended
> to handle new types.
I see that the minimal changes to make this compile & work for now
have been checked into cvs. Lets defer discussion of other changes
till we solve the higher-level problem of actually storing the new
objects.
My goal is to not have to write a hand-tuned, pure-custom-vlsi
backend for each and every new busienss object. I'd rather create
some config-file-driven thing, that will autogenerate 'the right thing'
either at compile time, or at run time, and still have good/excellent
query & table-join performance.
The crap with the m4 macros was a weak step in that direction,
its just m4 is not the right technology. I think I know how, but
it won't be quick or easy. Plus, I've got mixed feelings on a
'do-it-myself' approach, vs. finding something else on the net that
already does much of this ...
> > engine/Query.c
The queries need to be extended in a general way. An earlier note
described how.
--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