plongstaff at rogers.com
Mon Aug 10 10:08:35 EDT 2009
I am not and never was proposing to remove slots support. I was simply suggesting that I move well-established features out of slots and into the "normal" schema. The concern re XML was whether it should be done here as well.
OK. Given this and Derek's responses, I think what I will do is:
- in the engine, remove the flags from slots and move them into the main Account object
- in the sql backend, add the flags to the accounts table
- in the xml backend, convert flags to/from slots (and add as flags to the xml schema)
This will maintain backward compatibility with the xml format but also move it forward. In the future, we could drop storage in slots.
- in the engine, keep the info in slots - no change
- in the sql backend, create new budget_amounts table with id/budget_guid/account_guid/period/amount. Since slots are stored automatically, the data will be duplicated in the slots table.
- in the xml backend, no change
This will maintain backward compatibility but also make the budget amounts available to more normal SQL queries.
One reason for this is that I have been looking around for SQL report generators (open source equivalent to Crystal Reports) as a future replacement for our reports system.
From: "marcus.wolschon at googlemail.com" <marcus.wolschon at googlemail.com>
To: Gnucash list <gnucash-devel at lists.gnucash.org>
Sent: Monday, August 10, 2009 9:45:04 AM
Subject: Re: Db structure
One other thing:
I find the slots to be a very nice way to have new features in future
while older versions of the software can still read and edit the file
the values they don't know.
Very nice extensibility.
I think there is no need to break that.
+1 for changing the DB-shema for well establised features
-1 for changing the XML-schema at all
-1 for removing the Slots-support.
gnucash-devel mailing list
gnucash-devel at gnucash.org
More information about the gnucash-devel