[OPEN-ILS-DEV] Question about separation of shared database

Mike Rylander mrylander at gmail.com
Thu Mar 15 22:35:01 EDT 2007


On 3/15/07, Don McMorris <don.mcmorris at gmail.com> wrote:
> This is something going through my mind... I can think of a few
> scenarios where an "umbrella" library might exist sharing an ILS, but
> some data will need to be separated.  For example, all participants in
> the umbrella could see all bib and item records, but it would be
> undesirable for patron information to be shared systemwide.
>

Right.  There are other considerations, such as the requirement for a
unique barcode for items and patron cards.  There are ways to deal
with this, but all of them are sub-optimal on some level.

> Here's an example... A library management company decides to build and
> host an ILS for libraries that outsource to them.  They will ILL
> through each other, so all libraries' can see all bib/item records.
> However, user databases will be regional (or even library-specific).
>
> Another example... Another library management company decides to build
> and host an ILS for libraries that outsource to them.  Everyone will
> see every bib record (but perhaps the PAC can be configured to not
> show bibs without any viewable items attached).  Libraries in a
> specific region can see each others' item records for ILL purposes,
> but will not view item records for libraries outside that region.
> Patron databases are library-specific, though.
>

Permissions exist to restrict who can view patron records, and where.
Given a sufficiently deep hierarchy, yes, this can be restricted with
no problems (barring minor code adjustments).

> Is Evergreen configured so that (at the minimum) patrons' can be
> locked to certain libraries and not accessible by other libraries?
>

Now, there are certain interfaces that currently don't take this into
account (the patron search interface, for instance), but (and I'm just
blue-skying here -- Bill, don't shoot me) it should be an essentially
transparent change to restrict those interfaces.

The "big" problem would be giving the system the ability to use a
portion of the tree separate from the rest.  There are certain places
that look for the root of the OU tree by finding a node with no
parent.  This can be worked around by building an extra-OU institution
list that specifies the effective root, but that introduces issues for
extra-institution searching. ... it's a thorny problem, and we've
thought about it, but we don't have /all/ the answers yet.

> Thanks!
> --Don
>

-- 
Mike Rylander
mrylander at gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org


More information about the Open-ils-dev mailing list