search

duke-libraries / ezid-client

EZID API Version 2 client
BSD 3-Clause "New" or "Revised" License
11 stars 6 forks source link

Should be able to save without reloading #23

Closed dchandekstark closed 9 years ago

jcoyne commented 9 years ago

:+1: Yeah, this would bring a substantial speedup to my batch ingest process.

dchandekstark commented 9 years ago

@jcoyne Good to know. FWIW I use a resque job to handle the after_create minting, etc. asynchronously, but I still want to do this.

jcoyne commented 9 years ago

@dchandekstark: I'm trying to use the NOID part of the ark as my pid. Are you doing that?

dchandekstark commented 9 years ago

@jcoyne No, but we do set the EZID target to a URL containing the ARK -- which, currently, requires a modify operation after mint (although the EZID devs seem open to adding the functionality to optionally auto-set the target with a base URL + minted id or some such to avoid the second request). So, we're putting the ARK in an RDF property under the accessor permanent_id. After we back-assign permanent ids to all objects, we will try to hide Fedora's PIDs from UIs as much as possible so they will become purely internal ids.

Are you sure you want object creation to depend on EZID minting? It's pretty reliable, but we have experienced a few timeouts with the default Ruby net/http read timeout of 1 min (which they are investigating). Meanwhile ezid-client 0.13 and 1.0 provide a timeout option with a default of 5 minutes based on EZID's recommendation.