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 <[EMAIL PROTECTED]> 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... _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
