Db structure

[Derek Atkins]

Phil,

Phil Longstaff <plongstaff at rogers.com> writes:

> 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:
>
> For accounts:
> - 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.

Why does it matter whether the engine stores the info in the slots or
in a structure member?  Isn't it always accessed through an accessor
function?

If you move it into the xml schema then you have a problem where it's
stored in two places; you have to deal with the issue of what happens
if the two places don't match up.  And you still have to deal with the
"upgrade" logic to load the data from the slots in case it's not in the
xml schema portion.

> For budgets:
> - 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.

This is a fine idea in my mind.

> 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.
>
> Phil

Note that I think it would be reasonable to load from the xml
schema if it exists at this point, so that 2.4 knows how to read those
fields from the xml schema instead of the slots.  That would allow us to
move the data fulls to XML in the NEXT major version (2.6?  3.0?)

What I would do is delay the storage until the end.  So, e.g., instead
of using xaccSplitSetFlags() in the xml callback I'd store it in the
local version and only call SetFlags() in the end() routine, so that the
slots are already stored.  Of course this would write out the flags back
in the slots, but that's okay because we'll have the upgrade path later.

That's how I would do it....

-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