[Netarchivesuite-devel] Programmatical updates to the data model

Mikis Seth Sørensen mss at statsbiblioteket.dk
Fri Mar 25 14:02:58 CET 2011


Hi Nicolas

I've talked a bit with Søren about this issue.

The initial implementation of the updating of databases in the NAS project was to use sql scripts directly, but this was replaced by the programmatical approach to the database migration to simplify the upgrade process. We would therefore very much like to keep the application initiated update of the database, to avoid complication of the install procedure for our operations people.

That said, I think that a programmatical initiate database update could be combined with a upgrade definition specified in sql scripts. Then our need for an automatic database upgrade on application startup could be addressed by calling the sql scripts from the application code.

This would mean a NAS installation could chose between 2 database upgrade strategies:

 *   Manual database upgrade by running the migration script by a user with administrative priviliges.
 *   Automatic database database upgrade, where the application runs the same scripts.

Could this be a solution?
~Mikis


From: Nicolas Giraud <nikokode at gmail.com<mailto:nikokode at gmail.com>>
Reply-To: "netarchivesuite-devel at lists.gforge.statsbiblioteket.dk<mailto:netarchivesuite-devel at lists.gforge.statsbiblioteket.dk>" <netarchivesuite-devel at lists.gforge.statsbiblioteket.dk<mailto:netarchivesuite-devel at lists.gforge.statsbiblioteket.dk>>
Date: Wed, 23 Mar 2011 10:31:53 +0100
To: "netarchivesuite-devel at lists.gforge.statsbiblioteket.dk<mailto:netarchivesuite-devel at lists.gforge.statsbiblioteket.dk>" <netarchivesuite-devel at lists.gforge.statsbiblioteket.dk<mailto:netarchivesuite-devel at lists.gforge.statsbiblioteket.dk>>
Subject: [Netarchivesuite-devel] Programmatical updates to the data model

Hi,

I would like to get your opinion about the programmatic updates to the data model tables performed within NAS code (DBUtils#updateTable method called from DAO classes).

My own opinion is that it is not a good design to have this code embedded in the applicative code, for security reasons. It turns out that in most organizations, database administrators are in charge of production databases and are very stringent about security. For that reason, an applicative user will never be granted privileges to alter a table or a schema, or create a table. These operations are generally performed by DBAs themselves, using administrative accounts with extended privileges. This is the case here at BnF, and was also the case in most of my previous assignments.

We are currently putting 3.15 in production, and there have been changes to the datamodel. So rolling out this changes in production is painful, because the programmatic update code fails (the applicative DB user is not allowed to alter the DB schema), so I need everytime to manually create a script and forward it to the DBAs, who are not very happy with this "non-standard" course of events. So to be pretty honest, datamodel updates are currently a chore to roll out in production!

I believe that many potential users of NetArchive Suite might have the same type of organization and also experience these difficulties. So in my opinion, should we keep a programmatic approach to maintaining the data model (which is all right in itself), it should be made as a separate application, so that DBAs might be able to use these tool themselves, or at least identify a special account with the proper privileges.

What is your opinion about this matter ?

Best regards,

--
Nicolas Giraud
---------------------------------------------------------------------------------------------
Développeur Archives du Web - Bibliothèque Nationale de France
Web Archiving Developper - National Library of France
---------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.sbforge.org/pipermail/netarchivesuite-devel/attachments/20110325/e30ce36f/attachment-0002.html>


More information about the Netarchivesuite-devel mailing list