'gncentry' table mis-named

[Derek Atkins]

linas@linas.org (Linas Vepstas) writes:

> Well, at one point, we decided that "split" wasn't an accounting term,
> and that the correct term was Journal Entry or Entry for short, and 
> so all the code would be s/split/entry/g.   But this change was done 
> only in the sql backend, and not elsewhere.

Sigh....

> > However, I've already got another object called a
> > 'GncEntry', so I'd like to use that table name.
> > 
> > I'd like to rename the gncEntry table to gncJournalEntry.
> > 
> > Any objections?
> 
> Well, to do this, you need to write the upgrade script that will copy
> existing tables by this name to the new name.  You'd also need to  erase
> existing stored proceedures that use this name, and recreate thenm with
> the new name. And so on.  (src/backend/postgres/upgrade.c) This isn't 
> hard, but its not fool-proof either.  I think the risk of introducing 
> new bugs outweighs the name change ... 

Perhaps.  How many stored procedures are there?

> Wouldn't it be easier to rename the business-object-entry into something
> more descriptive?  Or if that doesn't work, how about calling the
> sql table something like GncBOEntry? I think that would be a lot easier
> ...

Maybe.  Maybe not.

I'm trying to make everything as "data-driven" and pluggible as
possible.  This includes the backends.  In fact, later today I'm going
to commit a change that basically allows modules to "plug in" new data
types into the backends.  Currently only the file (xml) backend
supports this new extension.

What this new extension means that if someone doesn't want the
business objects they don't have to have them.  They just don't
install the libraries and the engine is none the wiser!  The core
backend code knows nothing about these new objects (which means there
is no dependency on the business module code).

Obviously this means that as you add new objects to the system, you
need to supply new backend extensions for the objects, too.  But you
already needed to do that -- this extension just enables the
flexibility of doing so outside the core backend code.  What this is
doing is allowing each backend to provide its _own_ plug-in API with a
centralized location for registering.

The downside is that due to the way this works you cannot special-case
names of objects.  If an object is named "foo" then it is called
"foo".  Herein arrises the problem.  You've "special-cased" a split
into something else.

All is not lost.  This problem can still be worked around.  Moreover,
since I'm not working on SQL support we can still come up with a
workaround later.  However, special-case re-naming is not something
that I want to support, and it's a bad idea in general.

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