Re: 'gncentry' table mis-named
[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
Re: 'gncentry' table mis-named
On Mon, Mar 04, 2002 at 10:56:32AM -0500, Derek Atkins was heard to remark: 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? Maybe a half dozen. The real point is that there is an architected way to upgrade an existing gnucash database (as opposed to a global copy). Its not 'hard', but its not trivial, and it is error-prone if only because its under-tested. 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. I've spent some fair amount of time thinking about this type of generic problem (because gnucash isn't the only app with this problem) but have done zero about it. I want to make it super-easy to add an sql backend to an existing app. 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. I would strongly encourage adding a name-mapping between the c-object name and the sql-table name. I'm not sure how general your mechanism is, but if you have any hope of getting more general than what gnucash needs, having this kind of mapping would be a must-have feature. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) [EMAIL PROTECTED] PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: 'gncentry' table mis-named
[EMAIL PROTECTED] (Linas Vepstas) writes: I would strongly encourage adding a name-mapping between the c-object name and the sql-table name. I'm not sure how general your mechanism is, but if you have any hope of getting more general than what gnucash needs, having this kind of mapping would be a must-have feature. As I've been implementing the XML bindings, I realized that yes, you could make the SQL bindings take a table-name. So, yes, this would work. In fact, I wound up doing something like this for the XML extensions, to define the XML tag for each object. The way I've architected the backend-extensions, each backend defines it's own extension structure. Therefore, each backend can require whatever data and methods is needs. This also means that I didn't have to make any assumption about a generic backend extension. --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
'gncentry' table mis-named
I'm looking at data storage for the business modules, and I found a table called gncEntry. This table seems mis-named. It appears that this table is really a gncSplit, but I understand that Linas hates the name split. 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? -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
