Re: [Archivesspace_Users_Group] Database troubles upgrading from 1.4.2 to 1.5.1

[James Bullen]

Hi Brent,

It’s hard to be sure what’s going on here, but my guess is that at some point 
your 1.4.2 instance was running the container management plugin, but that it 
isn’t currently. That would explain what you’re seeing.

If my guess is right then a fix would be to add container management to your 
list of plugins just while you run setup-database.sh, something like this in 
config.rb:

AppConfig[:plugins] = [‘other’, ’stuff’, ‘container_management']

That would cause it to skip the container management migration - which would 
have run when the plugin was installed. It’s blowing up on trying to add a 
duplicate entry to the enumeration table (name has a unique constraint).

You can confirm this by looking at the tables in your database. If you see 
‘top_container’ then the container management migration has been run.

It’s possible you’ve landed in a bad state, so if it continues to fail, try 
starting again and just do the AppConfig tweak just before running 
setup-database.sh, and then remove it after.

Here’s the relevant migration:
https://github.com/archivesspace/archivesspace/blob/master/common/db/migrations/060_top_container_migration.rb

If this doesn't fix it then my guess is wrong - entirely possible! - and we’ll 
need to dig a little deeper.


Good luck!


Cheers,
James


> On Dec 2, 2016, at 7:27 AM, Brent Ellingson  wrote:
> 
> We are trying to upgrade a test instance of ArchivesSpace from 1.4.2 to 1.5.1 
> and we have run into some SQL errors that have prevented the upgrade. We are 
> using a copy of the production data.
>  
> Some help or suggestions would be greatly appreciated.
>  
> Here is basically what we have done.
> * Get a MySQL dump of the production DB
> * Copy the DB to a new server (now running MariaDB)
> * Installed ArchivesSpace 1.4.2
> * Started & indexed the 1.4.2 instance
> * Tested the 1.4.2 instance and it was running fine
> * Started the upgrade process for 1.5.1
> * Stopped the 1.4.2 instance
> * Unzipped the 1.5.1 archive to a new place
> * Copied the data files to the 1.5.1/data directory
> * Copied the config.rb
> * Copied the mysql jdbc jar to lib
> * Copied the plugins (we don't have any that I know of)
> * Checked the en.yml files
> * Ran the setup-database.sh script
> * Setup stopped due to a Database error
>  
> Here is the text of the error we are seeing from the log file:
>  Begin error log output 
> Loading ArchivesSpace configuration file from path: 
> /opt/archivesspace-1.5.1/archivesspace/config/config.rb
> Loading ArchivesSpace configuration file from path: 
> /opt/archivesspace-1.5.1/archivesspace/config/config.rb
> Running migrations against 
> jdbc:mysql://[DB_SERVER]:3306/[DB_NAME]?user=[REDACTED]=[REDACTED]=true=UTF-8
>  
> 
> 
> 
> 
> 
> 
> 
>  
>  3 
>  
>  
>  Database migration error. 
>  Your upgrade has encountered a problem. 
>  You must resolve these issues before the database migration can complete.
>  
>  
>  Error: 
>  # Java::ComMysqlJdbcExceptionsJdbc4::MySQLIntegrityConstraintViolationException:
>  Duplicate entry 'restriction_type' for key 'name'>
>  
> Java::ComMysqlJdbcExceptionsJdbc4::MySQLIntegrityConstraintViolationException:
>  Duplicate entry 'restriction_type' for key 'name'
>  
> java.lang.reflect.Constructor.newInstance(java/lang/reflect/Constructor.java:423)
> com.mysql.jdbc.Util.handleNewInstance(com/mysql/jdbc/Util.java:425)
> com.mysql.jdbc.Util.getInstance(com/mysql/jdbc/Util.java:408)
> com.mysql.jdbc.SQLError.createSQLException(com/mysql/jdbc/SQLError.java:935)
> com.mysql.jdbc.MysqlIO.checkErrorPacket(com/mysql/jdbc/MysqlIO.java:3970)
> com.mysql.jdbc.MysqlIO.checkErrorPacket(com/mysql/jdbc/MysqlIO.java:3906)
> com.mysql.jdbc.MysqlIO.sendCommand(com/mysql/jdbc/MysqlIO.java:2524)
> com.mysql.jdbc.MysqlIO.sqlQueryDirect(com/mysql/jdbc/MysqlIO.java:2677)
> com.mysql.jdbc.ConnectionImpl.execSQL(com/mysql/jdbc/ConnectionImpl.java:2545)
> com.mysql.jdbc.StatementImpl.executeUpdateInternal(com/mysql/jdbc/StatementImpl.java:1540)
> com.mysql.jdbc.StatementImpl.executeLargeUpdate(com/mysql/jdbc/StatementImpl.java:2603)
> com.mysql.jdbc.StatementImpl.executeUpdate(com/mysql/jdbc/StatementImpl.java:1604)
> java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:498)
> 

[Archivesspace_Users_Group] AS-102 : PDF export not only inclusive dates and include “Approximate,” “Inferred,” and “Questionable" labels

[Majewski, Steven Dennis (sdm7g)]

For some reason I appear to unable to add a comment to AS-102 in Jira, so 
posting it here:


PDF export not only inclusive dates and include “Approximate,” “Inferred,” and 
“Questionable" labels


https://archivesspace.atlassian.net/browse/AS-102



Although DACS model and ArchivesSpace describes more types of dates, the only 
allowed values for EAD unitdate/@type are “bulk” and “inclusive” . But @type is 
not required, so would it not be better to not include a @type attribute for 
date type “single” instead of mapping it to “inclusive” , which some people are 
finding confusing.


+1 for including unitdate/@certainty in EAD export and passing it thru to PDF 
output.


— Steve Majewski

___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] LCNAF import plugin

[Majewski, Steven Dennis (sdm7g)]

LCNAFConverter is just overriding and extending MARCXMLConverter.
https://github.com/archivesspace/archivesspace/blob/5e1ca66f1f04f142f2695024efb7200825046325/plugins/lcnaf/backend/model/lcnaf_converter.rb

There is very little MARC mapping in that code module —  it’s mostly in the 
base class, so look at:

https://github.com/archivesspace/archivesspace/blob/5e1ca66f1f04f142f2695024efb7200825046325/backend/app/converters/marcxml_converter.rb

https://github.com/archivesspace/archivesspace/blob/5e1ca66f1f04f142f2695024efb7200825046325/backend/app/converters/lib/marcxml_base_map.rb



The bulk of the code in the plugin deal with search and selection of MARC 
records to import.
MARC mappings are mostly inherited from above.



I would suggest:
[1] simplify by ripping out the OCLC import and only use 
id.loc.gov
[2] since there are multiple formats available from 
id.loc.gov service, and MARC mappings are complex and 
difficult to understand, I would consider writing a new importer from scratch 
for one of these alternate formats. 



— Steve Majewski



On Dec 1, 2016, at 1:02 PM, Lapka, Francis 
> wrote:

A group at Yale is exploring the possibility of developing data mapping 
improvements for the AS LCNAF import plugin. Could someone point me to the 
document(s) where the current mappings are documented? If such information is 
embedded in the code only, in which file(s) might I find it?

I’ve failed to unearth the information in my initial perusal 
ofhttps://github.com/archivesspace/archivesspace/tree/5e1ca66f1f04f142f2695024efb7200825046325/plugins/lcnaf,
 but perhaps I’m looking in the wrong places.

Thanks,
Francis


Francis Lapka  ·  Catalog Librarian
Dept. of Rare Books and Manuscripts
Yale Center for British Art
203.432.9672  ·  francis.la...@yale.edu


___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group