Yes, what I'm having to do is run "cleanup" until it fails, then look in the log for which bundle_id it failed on, then run a bunch of database queries trying to identify which row in bitstream the bundle.primary_bitstream_id points to, and which row it *should* point to, update the correct row in bundle.primary_bitstream_id, then re-run cleanup until it fails again. This is maddening!
-----Original Message----- From: Brian Freels-Stendel [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2008 3:34 PM To: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] "Cleanup" cron question I discovered a couple of weeks ago that we have it. I've been meaning to try to run down exactly where primary_bitstream_id is getting inserted (I assume it's wrong, since only 21 out of 8521 rows have it), but haven't found the time. Any help would be hugely appreciated. Brian Freels-Stendel UL LIT University of New Mexico >>> On 12/10/2008 at 1:24 PM, in message <[EMAIL PROTECTED]>, "Thornton, Susan M. (LARC-B702)[NCI INFORMATION SYSTEMS]" <[EMAIL PROTECTED]> wrote: > In DSpace 1.4.2, what exactly does the "cleanup" job do? For one > thing, I think it deletes assetstore entries for online records in > DSpace that have been deleted, however I'm wondering if it also deletes > "replaced" bitstream rows? For example, let's say a document for an > Item is corrupt and you "delete" that document and upload a new one, the > bitstream row for the original document doesn't actually get deleted in > DSpace - column bitstream.deleted gets set to "true". Is it the cleanup > job that is actually supposed to physically delete that old row in the > database? If not, how/when does it actually get deleted? I just > noticed that we have over 2,100 "duplicate" document names in the > database, mostly with 1 record marked as "deleted=true" and one marked > as "deleted=false". > > > > Also, has anyone reported having problems with "cleanup" failing > due to referential integrity problems with the "bundle" table? We've > had that problem for a looong time now and I just recently figured out > how to correct it. > > Thanks, > > Sue > > > > > > Sue Walker-Thornton > > ConITS Contract > NASA Langley Research Center > </></>Integrated Library Systems Application & Database Administrator > > 130 Research Drive > > Hampton, VA 23666 > > Office: (757) 224-4074 > Fax: (757) 224-4001 > Pager: (757) 988-2547 > Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > ------------------------------------------------------------------------ ------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix. com/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
