sqlite file format, anyone?

[Matthew Vanecek]

On Sat, 2003-06-21 at 22:54, Linas Vepstas wrote:
> On Sat, Jun 21, 2003 at 10:07:18PM -0400, Derek Atkins was heard to remark:
> > Matthew Vanecek <mevanecek at yahoo.com> writes:
> > 
> > > KVP tables.  
> 
> I'm going to play dumb for a moment.  What's wrong with storing the 
> triplet (keypath,value,guid-of-parent) where 'keypath' is the 
> slash-delimited list of keys? 
> 
> > > go backwards (i.e., refer back to *whatever* table from the KVP table
> > > based on the GUID).
> 
> Wouldn't this be solved by (keypath,value,guid-of-parent,type-of-parent)?
> 

Not really, unless you used table-name for type-of-parent.  In
Postgresql, you might could use OIDs, but that's highly non-portable.

> > > I'm hoping my version of the PG backend is pluggable enough that you can
> > > just plug-n-play the db access code.  The bulk of the work is in the
> > > Query decoding and Engine loading.  
> 
> I'm going to strongly disagree with this. Unless I misunderstand the
> statement. I did the 'obvious generalizations' as m4 macros (maybe not
> a good technology choice, but it was worth a shot).  But there's a 
> huge amount of code that's not m4 macros.  Its very specific, and its
> really needded to make things work correctly.
> 
> I initially thought that 95% of the code would be generic m4 macros,
> just 'query decoding and engine loading' but that turned out be not 
> the case; maybe only 25% is m4 macros.
> 
> I vastly underestimated how easy the sql backend would be; the complexity
> there was necessity, not frivolity.  I'm concerned that you'll trip
> over this too ...  See? you haven't even started, and already I'm saying
> 'I told you so' ... :-)
> 

Too late, already started.  Trying to fit it in around work and life is
a bitch, but I manage to get a bit done here and there.  Right now I'm
modelling the work I've already done so I can see where I'm at and what
I need to do.

Anyhow, a lot of the queries can be standardized on the SELECT/FROM
side--it's mainly the WHERE and ORDER BYs that are truly dynamic.

Certainly you are right--this is by no means a trivial task.  We're
dealing with people's financial data here.  That's another reason I'm
not rushing this (aside from life...), and, I fear, causing a bit of
anxiety for Derek. ;)  This type of application, however, is what I do
for a living.  Pretty graphics, flying ships, explosive charts--those
are all foreign items for me.  Database access, now, that's my
bread-n-butter. yum!

I tried the m4 route, too, for initial generation.  I think it works
well for that--getting the code base started.  It's difficult to
maintain, though.

Well, it's past my bed time, so have a good night!
-- 
Matthew Vanecek
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow except me.
I'm always getting in the way of something...