Hi Chris,
Although this is in the 1.3.3 RC1 tarball already, I'll give you my
reaction nonetheless.
> My thinking is to make all db updates which occur only in the types or
> functions of the database be handled by simply doing a module reload.
> This means dropping types if they exist, old versions of functions as
> necessary, etc. The database version woudl then be set to
> $request->{dbversion} (set in the LedgerSMB.pm).
As discussed, sometimes you need to change a function signature or
database table to resolve a bug - especially since we're moving more
and more logic into stored procedures; effectively those are becoming
the application.
Having a method which allows users to update their database in a
straight forward way seems really the best way to support this need.
> The major advantage here is that it makes downgrading within a 1.3.x
> series relatively possible. It might not be perfect and db tests
> might be required to see if anything was missed, but it would make
> things a lot easier.
I'm thinking downgrading only works if the old version also has the
DROP TYPE statements, which it currently doesn't. So, for the 1.3
series, I'd like to keep the focus on upgrading. If we made mistakes
on any 1.3.x, we should release 1.3.(x+1) asap anyway.
When moving onto 1.4, I'd say we could definitely look into making
downgrades part of the supported use cases.
Hope that's the kind of comment you were looking for?
Bye,
Erik.
------------------------------------------------------------------------------
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World™ now supports Android™ Apps
for the BlackBerry® PlayBook™. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
