We should come up with a case that we can replicate.
1.) Add Bitstream to Item, set as primary bitstream.
2.) Delete Bitstream
3.) Check if Primary Bitstream is still set (I suspect it is)
4.) Upload new bitstream, set as primary bitstream.
5.) Check if Primary Bitstream is properly set. (I suspect it isn't)
Thus if you've done Bitstream delete/add "replacements" without
resetting the primary bitstream, this will arise as a problem.
Solution:
1.) Create SQL JOIN Query to identify all the cases that deleted
bitstreams are still set as primary bitstream something like (very
untested)
> SELECT bitstream.bitstream_id, bundle.bundle_id,
> bundle.primary_bitstream_id FROM bitstream
> JOIN bundle2bitstream ON bitstream.bitstream_id =
> bundle2bitstream.bitstream_id
> JOIN bundle ON bundle2bitstream.bundle_id = bundle.bundle_id
> WHERE bitstream.deleted = true AND bundle.primary_bitstream_id =
> bitstream.bitstream_id
2.) In each case either:
2a) blast away primary bitstream id with wild abandon using SQL UPDATE
2b) attempt to find a pattern in the names that you can predictably
use to reassign primary bitstream id
3c) go through each case, by hand and reset appropriate bitstream as
primary.
Sorry, I suspect this may be a bug that will require hand fixing the
cases where it is broken.
-Mark
On Dec 10, 2008, at 12:45 PM, Thornton, Susan M. (LARC-B702)[NCI
INFORMATION SYSTEMS] wrote:
> 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
~~~~~~~~~~~~~
Mark R. Diggory
http://purl.org/net/mdiggory/homepage
------------------------------------------------------------------------------
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
