III wasnıt directly involved in this code, but Sierra customers to have
access the the Postgresql database behind the ILS. Itıs read-only so
thereıs no risk of breaking all your things.
James Van Mil
Collections & Electronic Resources Librarian
University of Cincinnati Libraries
[log in to unmask]
On 5/8/14, 2:38 PM, "Salazar, Christina" <[log in to unmask]>
>We don't run III Sierra but I'm still finding this news to be very
>You don't mention how III was involved (IF they were involved) and I'm
>curious to hear about that piece. For our vendor (not naming names)
>certain things that you might think to do with the database voids our
>maintenance agreement and I'm just wondering if that situation applies
>with III's Sierra.
>Thanks for sharing the news.
>John Spoor Broome Library
>California State University, Channel Islands
>From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
>Van Mil, James (vanmiljf)
>Sent: Thursday, May 08, 2014 11:29 AM
>To: [log in to unmask]
>Subject: [CODE4LIB] ActiveSierra - Gem for connecting to III Sierra db
>My colleague Sean Crowe and I have written a simple Rails engine with
>models for the Postgresql database backend to Innovative Interfaces Inc.
>Sierra ILS. Within a host rails app, it can be used to spin up mediated
>access to the database via Ruby objects. With a few additional
>controllers, it would also be straightforward to enable the serialization
>of database contents over http via json or xml. Though there is a pending
>release of API functionality for Sierra, this gem offers broader and more
>granular access to the database.
>See the github repo: https://github.com/uclibs/active_sierra/
>We're both primarily tech services librarians, and our first use cases
>for this gem have focused on back-end workflow. For example, we're
>developing a Rails app to track and report lost, missing, or long-overdue
>items in Sierra. With a rake task, a webapp will query Sierra monthly and
>build a local database of targeted item record numbers and values, which
>will be served to a site for use in making decisions about replacement.
>Other possible use cases could be record quality control reports.
>Out of security concerns, we've purposefully excluded models for patron
>tables but we haven't ruled out adding these once we can ensure the
>security of this data.
>We still have some short-term development planned, but we noticed that
>the repo was getting some attention yesterday, and thought it would be a
>good time to share. Some of our planned work includes:
>- Developing tests for the models and methods
>- Adding more scopes and methods to abstract the tables (we have a goal
>of making our testing application backend as friendly as possible to
>other tech services staff, and so we'd like the code to be readable to
>anyone who is familiar with both MARC cataloging and III system
>- Modeling additional tables
>Please feel free to use, fork or contribute. We are very open to comments
>and suggestions (especially from experienced Rails developers who may be
>able to offer some perspective on our direction - we both started
>learning about Rails at Code4Lib2013).
>And of course we welcome any questions.
>James Van Mil
>Collections & Electronic Resources Librarian University of Cincinnati
>[log in to unmask]