[Netarchivesuite-devel] Mysql Support in NAS

Mikis Seth Sørensen mss at statsbiblioteket.dk
Wed Apr 30 14:56:47 CEST 2014


Hi Andreas

I think it would be a VERY good idea to switch to PostgreSQL, as the
current support for multiple databases are causing a lot of problems
during releases where we struggle to get the different DB definitions and
update scripts to be consistent.

To address this problem Nicolas suggested we switched from Derby as our
testDB to H2, which can be run in Posgresql and Mysql compatibility modes,
which would enable us to avoid a special DB sql dialect for our test db
and at the same time make is possible to test postgres and mysql code as
part of the unit tests (see https://sbforge.org/jira/browse/NAS-2268). 	

If we could at the same time avoid having to maintain mysql specific code
in the NAS codebase it would be even better. This would mean we could go
from having to support 3 flavours to 1, which would makes life on NAS much
easier.

We have also discussed using a independent DB-Layer like hibernate (which
is already used in the nas wayback module), but if we could just obsolete
the necessity for support multiple database, we could avoid having to do
this.

Mikis

On 4/30/14 11:37 AM, "aponb at gmx.at" <aponb at gmx.at> wrote:

>I am wondering how good mysql will be supported in NAS in future and if
>it makes sense to keep using it. On the one hand we have the problem
>with modfied keysizes in mysql (from 1000 to 767) which forces us to
>change the size of some unique key contraints from 300 to 250, which is
>unfortunatly just a workaround and is obviously not compatible with the
>programmcode anymore, although it might work. And on the other hand we
>need to update mysql-skripts and MySQLSpecifics-Snippets to make NAS
>work with mysql for every new release (I still need to this before
>starting the relesase tests).
>What is your opinion, does it make sense to migrate to postresql, to
>avoid the problems with different schemas and the additional workload
>which is necessary to keep it running? Maybe a independent DB-Layer
>would be a solution, but of course this means a lot of changing code.
>Any thoughts on this?
>
>Regards
>a.
>_______________________________________________
>Netarchivesuite-devel mailing list
>Netarchivesuite-devel at ml.sbforge.org
>http://ml.sbforge.org/mailman/listinfo/netarchivesuite-devel




More information about the Netarchivesuite-devel mailing list