sqlite file format, anyone?

[Derek Atkins]

linas at linas.org (Linas Vepstas) writes:

> > "Setters" as you keep calling them are completely irrelevant.  What
> 
> OK. I thought it would make it easier to add the bus. obj.

Nope.

> > we need are hooks for the BackendRegistry, and we need to completely
> 
> ??  grep egistry  *.c doesn't give me anything.

Sorry.  I'm describing constructs, not object names.  From gncObject.h:

/** Register and lookup backend-specific data for this particular object */
gboolean gncObjectRegisterBackend (GNCIdTypeConst type_name,
				   const char *backend_name,
				   gpointer be_data);

gpointer gncObjectLookupBackend (GNCIdTypeConst type_name,
				 const char *backend_name);

void gncObjectForeachBackend (const char *backend_name,
			      foreachBackendTypeCB cb,
			      gpointer user_data);

> > re-write the Query* -> SQL conversion.  I already added comments
> OK.

I think this is a MAJOR piece of work!

> > in the PG code for where we'd need hooks into the BackendRegistry...
> > 
> > And then we'd need to implement the PGBackendAPI plugin for each of
> > the objects to add.
> 
> grep BackendAPI  */*.c give me nothing.

Again, this is a concept, not an actual object name.  Take a look at
src/backend/file/io-gncxml-v2.h for an example of a plug-in API.  Take
a look at src/business/business-core/file/*.c for examples of how this
API is used.

Each Backend needs to create its own plugin API.  I don't know what it
should be for PG.  It depends on the architecture of the backend, and
I dont know how the plugin parts are going to be needed for PG.  It
would clearly need at least load_book, begin_edit, commit_edit,
something to help perform the Query* -> SQL conversion and
query-results->object importation.  It might also require something
for period handling (different objects might need special handling
across a period).  But I dont know what it should look like, yet.

> > Isn't it?  It's what I've always been talking about.  The current code
> > doesn't have a clean separation (IMHO) between PG-specific and
> > SQL-generic code.  
> 
> No it doesn't, but shouldn't really be that hard.  There's one or two
> macros that are used for 100% of the calls, the macro can be changed.
> The only other thing is the 'logging onto the databse' code, which
> is very pg-specific.  But its not rocket science to do this, this is a
> small project.  Maybe a few days of work.

I dont think it's that little work.  Maybe it is, but I really dont
think so.

> > Another thing we need to do is rename the existing gncEntry table (to
> > gncSplit, or "Split), because there is another object (in the business
> 
> Yeah, OK.
> 
> > code) named gncEntry.  If Splits were to be called Entries then they
> > should have been globally renamed, not just renamed in the PG backend.
> 
> Well, that never happend, did it? I was being hounded because everyone
> kept telling me that split means stock split and that entry is the right
> term for it.  But the person who insisted the most didn't actually
> follow through.  Ugh.

One could say the same thing about lots of other things... Like the
"new QIF import" or even the "guile modularization"...  Lots of this
crap happens.  It's unfortunate, but then again this is "open source".
:(

> Crap like this is what makes me cranky and conservative.  I get real
> pissed when people come in and they say they'r gonna 'improve' things,
> and instead they break features without seeming to really improve
> anything at all. 

I agree, which is why I prefer seeing completed features before adding
them into the code.  I'll note that Matthew hasn't submitted changes
(other than getting the PG backend working again on recent PG).  I
believe his plan is to build a completely working implementation
before submitting it.

He also claims it will be much faster...  I don't know.

> > Personally, I think table-name should equal the GNC_ID_ string for any
> > object..
> 
> Yes.

ok. :)

I would also say that the column names should map directly to the
parameter names.  However there are always special cases.

> --linas

-derek

-- 
       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 at MIT.EDU                        PGP key available