[OPEN-ILS-DEV] make it simple

[Mike Rylander]

On Fri, Feb 29, 2008 at 10:41 AM, Kardos András <k.andris at gmail.com> wrote:
> Cheers,
>
>  Just wondering... Could make the import process a one-step thing? Or
>  document why you need the MARC -> Evergreen BRE JSON -> Open-ILS JSON
>  ingest -> PostgreSQL SQL steps. 3 out of 4 formats are invented by
>  you. That's too much. Couldn't you simply combine (package, hide, ..)
>  the scripts used in theese conversions into one? A clearly defined
>  MARC variant that you culd import (including holdings, ... etc. - all
>  special cases) would help a lot - the one, that would import quickly
>  and without pain into Evergreen. Then anyone exporting from another
>  system, would simply make a converter to this (required) MARC variant
>  if they wanted to avoid bumps along the way. Theese exporters (for
>  example from an OLIB system) could become the part of the Evergreen
>  package too. We would naturally share any piece of software we develop
>  for conversion from legacy (discontinued, ...) systems.
>

Don't get me wrong, I'm not against making demo migration simpler, but
experience (personally, 8 proprietary ILS products over about 20
migrations of differing complexity, some big players and some small)
tells me that it's simply not feasible to create a generic importer
that would be useful for more than a simple demo.  The differences
even among installations of the exact same ILS are great enough to

I think it would be great, and I'd welcome an attempt to do this.  It
doesn't cover any of the other data that you need to import that has
no standard format at all, such as patron, circulation and billing
data, and for certain things you'd want that data in first.  Then
there's circulation and hold policy, mapping of legacy fields to
statistical categories and notes, dealing with standard confounding of
location and status in legacy systems ...

I guess my point is that I've yet to run into a live, production
system that did not contain more exceptions than rules in the data.

>  Importing is a critical step, when you try to convince libraries to
>  try Evergreen, and eventually support it's development financially.
>  This long and complicated import process is just frightening. Sorry.
>  I'm a software developer. I could do it I guess, but I think it still
>  needs to be simplified a lot.
>

We're always looking for help where others feel an itch and would like
to scratch.  Those of us currently writing code for Evergreen are more
worried about features /after/ the setup and import than we are the
import itself.  To be honest, because the initial import happens
exactly once it's less of a priority than the things that need to
happen every day.

And again, that being said, we would welcome an open source migration
tool that would ease some of the initial setup burden.  It's just not
at the top of the priority list for anyone that is either currently
volunteering their time or being sponsored to develop for Evergreen.

>  I hope I don't sound to rurde.. :-)
>

You didn't, and I hope my response wasn't too rude either.

>  Thanks,
>  András Kardos
>
>  ... http://open-ils.org/dokuwiki/doku.php?id=evergreen-admin:importing:bibrecords
>  ...
>



-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com