I awoke around 4:48 am today. At the time, I thought it was just our
baby kicking away excitedly. However, later this afternoon, I realized
that it had been almost exactly a week ago, around 4:30 am on Monday, May 4th
that I sent a broadcast email message to librarians and staff at 24
different libraries. The Conifer consortial library system, built on
the solid foundations of the Evergreen
open-source library system, had gone live - and I was exhausted after
a long weekend of migrating all of that data. I was proud to see
the Laurentian catalogue sporting
a completely different look and new functionality - reviews! book covers!
sharable book bags! format & edition grouping! - and excited by the
promise of more to come.
Conifer represents the first flowering of an effort that began back
in July 2007 with a hand-shake agreement between
Laurentian University,
McMaster University, and the
University of Windsor to build a provincial,
primarily academic, library system on Evergreen. The system is centrally hosted
by the top-notch IT team at the University of Guelph.
Things change, and along the way Algoma University and the
Northern Ontario School of Medicine joined us
as full partners, and McMaster University opted to continue contributing to
the common development effort but withdrew from the centrally hosted system.
As noted, we went live on Monday, May 4th and we survived the first day. On Tuesday,
May 5th we corrected a problem in our configuration that had caused some instability
(thanks to Mike Rylander for providing the patch that set things straight). Since then,
we have been slowly refining aspects of the system - setting up circulation rules,
migrating records and items that had been missed over the weekend, polishing the Z39.50
server, fine-tuning the permissions scheme - but the core of the system is solid. We
have a consortial system that stretches from the southern-most tip of Ontario to the
north-west corner of the province (hello, Thunder Bay!), and so far connectivity seems
good and the reliability of the system - which, upon launch, has probably become the
second largest Evergreen implementation by number of bibliographic records - has been
superb.
A few interesting statistics about Conifer... (have I mentioned how much
I love that Evergreen is built on PostgreSQL because it becomes so simple to
generate basic reports in plain SQL?):
Number of staff and user accounts per library in Conifer
conifer=# SELECT aou.name, count(au.id)
FROM actor.org_unit aou
INNER JOIN actor.usr au
ON aou.id = au.home_ou
GROUP BY aou.name
ORDER BY 2 DESC;
name | count
--------------------------------------------+-------
Leddy Library | 19468
J.N. Desmarais Library | 11921
Algoma University, Wishart Library | 2431
University of Sudbury | 1100
Hearst, Bibliothèque Maurice-Saulnier | 1043
Huntington College Library | 834
Paul Martin Law Library | 592
Northern Ontario School of Medicine (West) | 284
HRSRH Health Sciences Library | 261
Northern Ontario School of Medicine (East) | 224
Xstrata Process Support Centre Library | 122
NOHIN | 121
Instructional Media Centre | 9
Laboratoire de didactiques, E.S.E. | 7
Vale Inco | 4
Mines Library, Willet Green Miller Centre | 2
Art Gallery of Sudbury | 1
Curriculum Resource Centre | 1
Sault Area Hospital | 1
Centre Franco-Ontarien de Folklore | 1
Conifer | 1
(21 rows)
Number of copies held per library in Conifer
conifer=# SELECT aou.name, count(ac.barcode)
FROM actor.org_unit aou
INNER JOIN asset.copy ac
ON aou.id = ac.circ_lib
GROUP BY aou.name
ORDER BY 2 DESC;
name | count
--------------------------------------------+---------
Leddy Library | 1373197
J.N. Desmarais Library | 614380
Paul Martin Law Library | 229391
Algoma University, Wishart Library | 115156
University of Sudbury | 42154
Hearst, Bibliothèque Maurice-Saulnier | 34276
Huntington College Library | 12517
Laboratoire de didactiques, E.S.E. | 10284
Mining and the Environment Database | 9940
HRSRH Health Sciences Library | 7512
Music Resource Centre | 7511
Xstrata Process Support Centre Library | 5477
Centre Franco-Ontarien de Folklore | 4365
Northern Ontario School of Medicine (East) | 3779
Northern Ontario School of Medicine (West) | 3301
NOHIN | 2647
Mines Library, Willet Green Miller Centre | 2617
Curriculum Resource Centre | 2583
Sault Area Hospital | 2515
Art Gallery of Sudbury | 2237
Hearst Timmins, Centre de Ressources | 2202
Hearst Kapuskasing, Centre de Ressources | 2007
Vale Inco | 1106
Instructional Media Centre | 1095
(24 rows)
What about acquisitions, serials, and reserves?
One of the reasons we had a hard migration date of early May was because
it matches nicely with the fiscal year-end for those institutions who were
running a traditional acquisitions system on their legacy ILS. We normally
shut down all purchases for a period of weeks while we roll over the encumbrances
into the next fiscal year and set up our budgets. This year, we're migrating all
of the old financial data twice: first, and foremost, into the most sophisticated
set of spreadsheets you'll ever see attached to a library system (as pulled together
by the inestimable Art Rhyno); and second, into the Evergreen acquisitions system
that will launch with Evergreen 1.6. The first migration of a given set of data
is always the hardest part, so once we have the fund / order / provider data in
spreadsheets, the migration into Evergreen proper will be trivial. This will give
us the summer to use both systems side-by-side and refine what we need from Evergreen.
We have migrated all of our serials data from the legacy system, I just haven't
enabled the display of that data in our live system. A prototype was running on
my laptop for a few days until I accidentally blew it away - ah well, anything
worthwhile doing is better the second time around anyway. This, too, will be
part of the Evergreen 1.6 release, and will feature full MFHD compliance built on
the code that David Fiander has been writing on behalf of Equinox. I should note
that this first cut at serials is in some ways relatively basic; while the system in
Evergreen 1.6 will be fully MFHD compliant, down to the point of letting you to
edit an MFHD record to "check in" a new issue by adding a new 863 field, it won't
associate barcodes with individual issues. Most of the database schema exists to
support that, but there's still a large amount of code to be written on top of the
schema and we need Something That Works Right Now
I'm confident that that's coming
not too far down the road, though.
Finally, what would an academic library be without reserves? Art Rhyno (again!) has
been working with Graham Fawcett for the past six months on
Syrup -
a really impressive melding of the world of electronic reserves and traditional
physical library system reserves that uses SIP and Z39.50 to talk to Evergreen.
Syrup is just about at a full boil now, so in a few more weeks we should have it
deployed so that we can savour its sweetness through the relatively slow summer
months before ensuring that the taste is just right for all of our incoming students
and faculty in the fall.
Here in closed-source legacy world Evergreen is starting to gain the attention of even the most die-hard traditionalists.
Good luck!
And the OPAC is available en français aussi!
Yahoo!!!
There is admittedly still a lot of work to do to polish the French interfaces, both public-facing and in the staff client, but the bulk of the work is done. Offering a truly equal bilingual experience is critical for us, so expect to see more refinements over the next few months.
Nice job.
I've been watching to see what I can use from all you smart folks!
Thank you and everyone else who have put in the long hours in making it happen!
BTW, thanks for that handy SQL -- just what I needed as we get to doing some post-migration reports.
Tigran
Your pals at Project Sitka.
Change of subject, but I didn't know who else or where else to ask (and its a non-trivial question).
I work in a shop where there is mild, but constant, pressure to standardize, so our sys admins aren't driven mad by too much variety. Here's what I mean:
- Virtualization - what ever "it" is, "it" has got to ultimately be virtualizable (sic). We have a VMWare ESX server attached to ginormous SAN.
- OS's of choice are either:
a) Windows Server, usually one release back from whatever MS is flogging as the latest and greatest. So if the latest is Windows Server 2008, we're running Windows Server 2003. Usually because an application vendor is finally able to support '2003 over '2000.
b) RHEL. RHEL 4 is the flavor of choice at the moment, but movement to RHEL 5 will happen Real Soon Now.
- Databases of choice are either:
a) Oracle 10gR2, with people beginning to think of moving to 11gR1. The determining factor here is, again, whether an application vendor is ready to move up.
b) MS SQL Server.
Exceptions: there are always exceptions. One of them is a balance between vendor support for virtualization and performance.
For example, I know of a prominent, North American, library automation vendor who says "yeah, we know of customers running our app under VMWare, but we haven't tested it yet, so we can't support it."
Contrast that with another vendor for an entirely different product who says "yep, we've tested our app on physical servers, virtual servers, and a mixture of physical & virtual servers. In your case, we can see you virtualizing the app but keeping the database on a physical server. You can do what you want, but we think a mixed set of servers is best."
What I'm musing about is what the level of effort is to replace PostgreSQL with Oracle? And would you:
- Put the app and database on a single physical server or
- a single virtual server or
- a pair of physical servers (one for the app, another for the database) or
- a pair of virtual servers or
- a mixture of a servers - a virtual server (for the app) and a physical server (for the db)
Of course this is for self-hosting. If we hosted Evergreen in a way its much simpler. The hosting folks figure out how to run the app; the customer figures out how to pay, and justify paying for, remote hosting over self-hosting.
A simpler question is "How hard is to use Oracle instead of PostgreSQL in Evergreen?"
Many thanks,
Mark A.
The emphasis came from the *asterisks*; I've edited your comment to remove that unintended highlighting
Long story short, I would say that virtualization is probably a good option for the Web / application servers that make up the bulk of an Evergreen solution, with physical hardware for the database server(s). That said, we went with traditional physical servers throughout due to a lack of time to test and compare the virtualized approach. Perhaps over time we'll move to a more virtualized solution.
Also, to address the "support Oracle" question - it would take a lot of work to make that happen. Evergreen makes use of a number of PostgreSQL extensions that are extremely convenient but which also introduce some portability challenges. And those extensions aren't confined to just a single file or a well-defined set of files. You would have to start with the schema (Open-ILS/src/sql/Pg/ directory) and work with the open-ils.cstore (C database abstraction API) and open-ils.storage (Perl database abstraction API) applications, and then see what else breaks...
Yep, I figured that PostgreSQL and Oracle had different SQL syntax, to say nothing of their own, unique features that developers might choose to take advantage of.
I hadn't given any thought to a lower, database dependent layer that knits Eg to Pg "down in the engine room." Hmmm...not the best place to start learning C!