[EMAIL PROTECTED] (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 [EMAIL PROTECTED] PGP key available _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel