Difficulty migrating ICA-Atom database from 1.2 to 1.3...

[Mike B]

Hi there,

I'm trying to upgrade our ICA-Atom instance to the latest 1.3 from SVN and I've run into a snag which has me a bit perplexed, not being PHP-savvy. The app itself seems to run okay until I try to log in, whereupon I get the following error:

[wrapped: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'user.ACTIVE' in 'field list']

Fair enough, there have obviously been some schema changes.

The I try and migrate the database using:

php symfony tools:upgrade-sql

This gives me the following error:

>> backup    Backing up database "icaatom" to db_20121016144506.sql.bak

>> backup    Database backup complete!

>> upgrade-sql Upgrading from Release 1.1

>> upgrade-sql Upgrading from Release 1.2

PHP Fatal error:  Class QubitTerm contains 4 abstract methods and must therefore be declared abstract or implement the remaining methods (ArrayAccess::offsetExists, ArrayAccess::offsetGet, ArrayAccess::offsetSet, ...) in /home/michaelb/dev/php/ehri-ica-atom/lib/model/QubitTerm.php on line 30

I'm a bit perplexed as to why this happens, since none of the mentioned files have been in any way modified, and the PHP version (PHP 5.3.10-1ubuntu3.4) isn't out of the ordinary. Does this error suggest anything obvious that I may have missed?

Thanks in advance,

Mike

[David Juhasz]

Hi Mike,

Please see an explanation and fix for this issue in our FAQ:
https://www.qubit-toolkit.org/wiki/FAQ#Why_do_I_get_a_.22Class_QubitActor_contains_4_abstract_methods.22_error.3F



Regards,
David

--
David Juhasz
Director, Technical Services

Artefactual Systems Inc.
www.artefactual.com

[Mike B]

Excellent, thanks David!

[Mike B]

Hi David - sorry, I've hit another snag with this. Do you have any suggestions for tackling the following error:

Error

SQL query:

ALTER TABLE `information_object` CHANGE `identifier` `identifier` VARCHAR( 1024 ) CHARACTER SET utf8 COLLATE utf8_general_ci NULLDEFAULT NULL

MySQL said: 

#1071 - Specified key was too long; max key length is 767 bytes 

I get this when migration 83 tries to change the size of information_object.identifier and repository.identifier (which actually have values in them.)  I have temporarily got the full migration to apply by commenting out the changes to these tables, but obviously this isn't an ideal solution.

Googling this error brings up a variety of apparent solutions related to Mysql limits, but none seem to work in my case, even if I try to change the values manually.  I'm using the Innodb engine (which was apparently the default when the DB was created) and the utf8_general_cl encoding, with MySQL 5.5.24-0ubuntu0.12.04.1 on Ubuntu.

Many thanks,

Mike

[Mike B]

(And wow - the new theme looks fantastic - you guys have done a great job with this version.)

[David Juhasz]

On 12-10-18 03:35 AM, Mike B wrote:

Specified key was too long; max key length is 767 bytes

According to this post:
http://stackoverflow.com/questions/1814532/1071-specified-key-was-too-long-max-key-length-is-767-bytes

InnoDB only supports a maximum UNIQUE index prefix length 767 characters for InnoDB tables.

The default ICA-AtoM data schema does not include an index for the information_object.identifier or repository.identifier columns, have you added an index manually to your version of the software?

It looks like it should be possible to increase the column width by dropping the current index adding a prefix length to the unique constraint:

ALTER TABLE `information_object` DROP INDEX index_name;
ALTER TABLE `information_object` ADD UNIQUE ( identifier(767) );

Note you will need to substitute "index_name" with the name of the appropriate index in your database.

[David Juhasz]

P.S. If the current column widths are working for you, then there is no
need to increase them. We have had several users complain that the
title of their descriptions were being truncated, so we increased the
width of ALL of the text fields in the database to avoid similar
issues. However, there is no need to increase the column widths if you
are not having problems with data being truncated.

[Mike B]

Thanks again David - I think I'll just stick with the commenting-out approach for now!