[mir-coders] tracking updates to the db
pietro at indymedia.org
Thu Sep 8 14:41:47 PDT 2005
zapata had a better ideia of having a table with only one field to hold a
version of the db model your mir is using. i have a small patch for that.
i named the new table "db_model" and it has just one field called
"version". versions will of the form mir_version-patch_level, so the 15th
update to the db of 1.1 will leave you with version "1.1-15".
my two questions now are:
what should be the version we are running atm be called? 1.1-0, 1.1-1?
should i throw away the other patch? i like the idea of being able to
document what upgrades are doing to my db. perhaps i might try to add a
page in the admin interface where site admins can see which updates were
aplied and what each one does.
On Thu, September 1, 2005 4:41 pm, pietro wrote:
> hi folks,
> i was thinking about a way to keep track of which updates were applied to
> a db to make admins lives easier and also to make it possible for a script
> to update a mir installation withou having to run all the db update
> scripts when just a few or none are needed.
> i came up with the idea of using a table to keep track of which updates
> were applied to a db. it has an id, a date and a description of the
> i'm attaching a diff to the create_pg.sql and createmirdb.sh scripts to
> get the table created in a new install. the populate_dbpatches.sql is to
> get the a new db with the data of the patches written so far and the
> update20050901.sql is an update that existing sites should run.
> i appreciate any comments, ideas and criticism. please remember that i'm
> not an expert in databases and nor postgres.
> mir-coders mailing list
> mir-coders at lists.indymedia.org
More information about the mir-coders