Skip to end of metadata
Go to start of metadata

Documentation and installation

Documentation for CollectionSpace version 3.2.2, including downloading and installation instructions.

Overview

CollectionSpace's version 3.2.2 release includes various performance improvements and bugfixes, building on the previous minor release, 3.2.1. These changes were made by software developers at UC Berkeley as contributions to CollectionSpace.

The focus of this release is on improving the responsiveness of partial term matching (CSPACE-5941), the process through which matching authority terms appear dynamically in a dropdown menu, as you type into an 'autocomplete' field. In testing on a very large CollectionSpace system, speedups ranging from two to six times were obtained for some term matching queries.

This release also includes one other general performance-related change, as well as several minor bugfixes, mostly related to importing records via the Imports service.

Release date and schedule

CollectionSpace version 3.2.2 was released on April 16, 2013.

March 5, 2013: Development Begins
April 10, 2013: Development Ends
April 11-15, 2013: QA Testing
April 16, 2013: Release

Release notes

New functionality

Automatic population of metadata refName values during import (CSPACE-5845)

When importing records via the Imports service, values are now automatically populated into a metadata field, collectionspace_core:refName.

With nearly all record types, these values are automatically generated from provided data; in the case of authority item (term) records, they are obtained from the user-supplied refName value in the imported records.

Schema additions

None so far.

Performance-related changes

Improving the performance of partial term matching (CSPACE-5941)

The performance of partial term matching - where, as you type into an 'autocomplete' field, terms dynamically appear in a dropdown menu below that field - has been improved overall. In particular, there are significant - between two- and six-fold - performance gains when searching for especially problematic terms matching large numbers of records, on systems with very large datasets (e.g. tens of thousands of terms in term authorities and, collectively, millions of records across all types). This was done by replacing the SQL query automatically generated by the Nuxeo content management system with a hand-tuned query.

See this comment on CSPACE-5941 for comparative timings during testing, and this comment on PAHMA-813 for 'real world' comparative timings on one museum's system.

By default, a maximum of 40 preferred terms (not including non-preferred variants of those terms) are now returned from any partial term matching query, to be displayed in the dropdown menu below an autocomplete field. This maximum value can be adjusted on a per-tenant basis, by adding a property similar to the following to Services' tenant bindings:

Elimination of many extraneous requests between Application and Services layers (CSPACE-5391)

When CollectionSpace's Application layer makes a request to its Services layer, it now includes authentication credentials in the initial request. Formerly, the initial request would always be met with an authentication challenge (a '401 Unauthorized' response), and a follow-up request would then need to be made to provide those credentials.

This minor change eliminates many extraneous HTTP requests made between these layers, and has the potential to at least modestly speed up loading of data into pages.

Bugfixes

Values in certain columns in structured date popups are once again fully visible (CSPACE-5906 and CSPACE-5967)

This bugfix resolved a CSS styling problem where certain table columns in structured date popups had either partly cut off the visibility of data (e.g. a portion of the right-most digit in the Year field), or entirely obscured data (in the Era, Certainty, and (Qualifier) Unit columns).

Searches for users now match on separate words (CSPACE-2029)

On the Administration -> Users tab, searches for users now match on separate words, and also on same-ordered text fragments found in names, behavior that had long been functionally expected. A search on "Joe Briggs", for example, now returns users "Joe Bob Briggs" and "Joe L. Briggs" as well as "Joe Briggs". And a search just on "Joe B" will also return all three users.

URI values emitted in 'all authorities' search results are now accurate (CSPACE-5956)

A bug was fixed that, when searching for authority terms across multiple vocabularies (across every vocabulary for Storage Locations, for instance), could cause the authority CSIDs in <uri> values in list results to be incorrect for some records, as this value was inappropriately cached from its value from the first record in the list. (This bug did not affect system behavior, as those values - erroneous or otherwise - are not currently used in record retrieval.)

Multiple bugfixes when importing records with extended schemas (CSPACE-5947 and CSPACE-5948)

Two bugs were squashed when importing records with extended schemas via the Imports service. (Extended schemas are those which include custom fields, beyond those provided in CollectionSpace's default schemas.) One bug had resulted in an Exception that could cause an import to fail, while the other resulted in missing values in a metadata field, collectionspace_core:uri.

Imports of authority records containing ampersands in refNames now work (CSPACE-5940)

A bug was fixed that resulted in an Exception that could cause an import via the Imports service to fail, when an authority-related record was imported that contained one or more ampersands (&) in the display name portion of its refName value. This bug was introduced along with the new functionality provided in CSPACE-5845, above.

System requirements changes

None.

However, the use of PostgreSQL 9.2 or later may be helpful in fully realizing the performance gains described above, related to partial term matching. This is due in part to the generation of better query plans with certain JDBC prepared statements, and in part to the possibility of using index-only scans in some queries. (There may also potentially be other relevant performance gains due to other changes introduced in version 9.2, although these have not been examined.)