Thanks, Eric. Those sound like useful approaches. We'll probably end up doing something similar.
-- Scott On 10/10/2013 07:27 PM, James, Eric wrote: > Hi Scott, > > Regarding (1), we are implementing using activefedora logic that in the > rescue block checks if the object has been saved and if so deletes it if an > error occurs This error gets tracked in our database managing the queue of > objects to be ingested. I find this pretty clean. But you could probably do > any of the options you mention. For each content model we also have tables > that hold the expected datastreams and whether they are required, and if a > required datastream is missing that object fails. > > Regarding (2), initially we rolled back the entire parent/children if a child > fails, but realized that would be a waste of effort (i.e. deleting an 1000 > child parent because child 999 failed). Instead the error in the child is > flagged in the tracking database for reprocessing and the interface is > designed to handle missing children. Alternately I could see it working well > to inactivate the parent upon child error depending on the type of content > you have, the kinds and frequency of the errors you might encounter, and > application design, etc. > > -Eric > > > ________________________________________ > From: Scott Prater [pra...@wisc.edu] > Sent: Thursday, October 10, 2013 10:29 AM > To: Fedora Commons > Subject: [fcrepo-user] Managing errors in an object ingest/update/purge > workflow? > > I have some curiosity about how others handle transactions and rollbacks > when ingesting/updating objects and datastreams, using the RESTful API. > > Here are the scenarios we encounter: > > 1. We create an object, then try to ingest a critical datastream (say, > RELS-EXT, or DC). The datastream ingest fails. Do you then destroy the > object? Do you mark it inactive? Some other flag to indicate it is in > an inconsistent state? Or do you sweep your repo periodically, looking > for objects in an inconsistent state? > > Do you handle non-critical datastream failures differently (say, an > optional datastream?) > > 2. We create a parent object, then a series of child objects. One of > the child objects fails to be created (perhaps because of a datastream > ingest failure, as described above). Do you then destroy the entire > tree of objects, as the whole hierarchy is now in an inconsistent state? > Or do you somehow indicate in the parent object that its descendants > are incomplete? Or, as above, do you regularly sweep the repo, and > verify all the relations between objects, report dangling pointers? > > I'd be very interested to hear about practices that others have > implemented in production that have worked well for them. > > thanks in advance, > > -- Scott > -- > Scott Prater > Shared Development Group > General Library System > University of Wisconsin - Madison > pra...@wisc.edu > 5-5415 > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > _______________________________________________ > Fedora-commons-users mailing list > Fedora-commons-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > _______________________________________________ > Fedora-commons-users mailing list > Fedora-commons-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users > -- Scott Prater Shared Development Group General Library System University of Wisconsin - Madison pra...@wisc.edu 5-5415 ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk _______________________________________________ Fedora-commons-users mailing list Fedora-commons-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
