subject:"Re\: \[Dspace\-tech\] \"Cleanup\" cron question"

Re: [Dspace-tech] "Cleanup" cron question

2008-12-11 Thread Thornton, Susan M. (LARC-B702)[NCI INFORMATION SYSTEMS]

We only have .pdf and .doc files in our repository, so as it turned out
the only rows in the bundle table that had a value in
primary_bitstream_id were the problematic ones.  I wonder how it
happened though...??  It may have something to do with the admin
interface where you can delete a document and then upload another one,
probably in the same session, I'm thinking, since we don't do much of
this and we only had about 12 mismatched rows in the table.  In most of
the cases, there were 3 rows in the bitstream table tied to a single
Item - two .pdf rows and one .pdf.txt row, and one of the .pdf rows was
marked as "deleted".  In one odd case though, I found two .pdf rows and
two .pdf.txt rows for the same Item and all four were marked as
"deleted", yet there was still a value in the associated bundle row in
primary_bitstream_id.  Oh, and there was *no* associated
bundle2bitstream row.  Strange.

 

Sue

 



From: Diggory Mark [mailto:mdigg...@gmail.com] 
Sent: Wednesday, December 10, 2008 6:13 PM
To: Thornton, Susan M. (LARC-B702)[NCI INFORMATION SYSTEMS]
Cc: dspace-tech@lists.sourceforge.net; Smail, James W. (LARC-B702)[NCI
INFORMATION SYSTEMS]
Subject: Re: [Dspace-tech] "Cleanup" cron question

 

However, primary_bitstream_id is used by the application even in 1.5 to
identify the case when only one bitstream should be exposed in the UI
(for instance an Item containing a website in HTML).  This is not
functionality that has "gone away".

 

-Mark

 

On Dec 10, 2008, at 2:34 PM, Thornton, Susan M. (LARC-B702)[NCI
INFORMATION SYSTEMS] wrote:





Wow!  I just answered my own question, thanks to an idea I got from
Brian's reply to my question ("It seems to me I've seen that the
primary_bitstream_id and the mets_bitstream_id are both unused fields,
and should be Null."...:-)  Yes, the cleanup job DOES physically delete
all the rows in the bitstream table where "deleted is true".  I ran the
following SQL query to correct the relational integrity problems between
the bundle and bitstream tables:

 

UPDATE bundle

   SET primary_bitstream_id = NULL

WHERE primary_bitstream_id > 0

 

Once I ran this query (it updated 7 rows in the bundle table), I was
able to get "cleanup" to run to successful completion, and YES - it
deleted all those rows in the bitstream table that were "marked" for
deletion.

 

For those of you who either don't have this problem or don't KNOW you
have this problem, look in dspace.log after your "cleanup" job runs.
You may see something like:

 

2008-12-10 15:19:00,921 FATAL org.dspace.storage.bitstore.Cleanup @
Caught exception:

org.postgresql.util.PSQLException: ERROR: update or delete on table
"bitstream" violates foreign key constraint "$2" on table "bundle"

  Detail: Key (bitstream_id)=(43213) is still referenced from table
"bundle".

at
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecu
torImpl.java:1592)

at
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImp
l.java:1327)

at
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:
193)

at
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Stateme
nt.java:452)

at
org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdb
c2Statement.java:351)

at
org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2S
tatement.java:305)

at
org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(Delega
tingPreparedStatement.java:101)

at
org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(Delega
tingPreparedStatement.java:101)

at
org.dspace.storage.rdbms.DatabaseManager.updateQuery(DatabaseManager.jav
a:519)

at
org.dspace.storage.rdbms.DatabaseManager.updateQuery(DatabaseManager.jav
a:547)

at
org.dspace.storage.rdbms.DatabaseManager.deleteByValue(DatabaseManager.j
ava:702)

at
org.dspace.storage.rdbms.DatabaseManager.delete(DatabaseManager.java:669
)

at
org.dspace.storage.bitstore.BitstreamStorageManager.cleanup(BitstreamSto
rageManager.java:663)

at
org.dspace.storage.bitstore.Cleanup.main(Cleanup.java:109)

 

 

The reason why you may not know you have the problem is because the
cleanup cron does not check for return code after executing.  I just
happened to notice the above error in dspace.log one day and, after
adding the following code to the cleanup cron, I began to see that
cleanup never completed successfully:






# Shell script for cleaning the asset store.

 

# Get the DSPACE/bin directory

BINDIR=`dirname $0`

 

echo "Clean

Re: [Dspace-tech] "Cleanup" cron question

2008-12-10 Thread Diggory Mark

However, primary_bitstream_id is used by the application even in 1.5  
to identify the case when only one bitstream should be exposed in the  
UI (for instance an Item containing a website in HTML).  This is not  
functionality that has "gone away".


-Mark

On Dec 10, 2008, at 2:34 PM, Thornton, Susan M. (LARC-B702)[NCI  
INFORMATION SYSTEMS] wrote:


Wow!  I just answered my own question, thanks to an idea I got from  
Brian’s reply to my question (“It seems to me I've seen that the  
primary_bitstream_id and the mets_bitstream_id are both unused  
fields, and should be Null.”…J  Yes, the cleanup job DOES physically  
delete all the rows in the bitstream table where “deleted is true”.   
I ran the following SQL query to correct the relational integrity  
problems between the bundle and bitstream tables:


UPDATE bundle
   SET primary_bitstream_id = NULL
WHERE primary_bitstream_id > 0

Once I ran this query (it updated 7 rows in the bundle table), I was  
able to get “cleanup” to run to successful completion, and YES – it  
deleted all those rows in the bitstream table that were “marked” for  
deletion.


For those of you who either don’t have this problem or don’t KNOW  
you have this problem, look in dspace.log after your “cleanup” job  
runs.  You may see something like:


2008-12-10 15:19:00,921 FATAL org.dspace.storage.bitstore.Cleanup @  
Caught exception:
org.postgresql.util.PSQLException: ERROR: update or delete on table  
"bitstream" violates foreign key constraint "$2" on table "bundle"
  Detail: Key (bitstream_id)=(43213) is still referenced from table  
"bundle".
at  
org 
.postgresql 
.core 
.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java: 
1592)
at  
org 
.postgresql 
.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1327)
at  
org 
.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java: 
193)
at  
org 
.postgresql 
.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
at  
org 
.postgresql 
.jdbc2 
.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java: 
351)
at  
org 
.postgresql 
.jdbc2 
.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:305)
at  
org 
.apache 
.commons 
.dbcp 
.DelegatingPreparedStatement 
.executeUpdate(DelegatingPreparedStatement.java:101)
at  
org 
.apache 
.commons 
.dbcp 
.DelegatingPreparedStatement 
.executeUpdate(DelegatingPreparedStatement.java:101)
at  
org 
.dspace 
.storage.rdbms.DatabaseManager.updateQuery(DatabaseManager.java:519)
at  
org 
.dspace 
.storage.rdbms.DatabaseManager.updateQuery(DatabaseManager.java:547)
at  
org 
.dspace 
.storage.rdbms.DatabaseManager.deleteByValue(DatabaseManager.java:702)
at  
org.dspace.storage.rdbms.DatabaseManager.delete(DatabaseManager.java: 
669)
at  
org 
.dspace 
.storage 
.bitstore 
.BitstreamStorageManager.cleanup(BitstreamStorageManager.java:663)
at org.dspace.storage.bitstore.Cleanup.main(Cleanup.java: 
109)



The reason why you may not know you have the problem is because the  
cleanup cron does not check for return code after executing.  I just  
happened to notice the above error in dspace.log one day and, after  
adding the following code to the cleanup cron, I began to see that  
cleanup never completed successfully:



# Shell script for cleaning the asset store.

# Get the DSPACE/bin directory
BINDIR=`dirname $0`

echo "Cleaning the asset store"

$BINDIR/dsrun org.dspace.storage.bitstore.Cleanup


# Check to see if the program executed successfully
if [ "$?" -ne "0" ]; then
   echo "cleanup cron failed"
   exit 1
fi

echo "cleanup cron completed successfully!"
exit 0
*

Thanks to everyone who responded to my post!
Happy Holidays!!
Sue

From: Thornton, Susan M. (LARC-B702)[NCI INFORMATION SYSTEMS] [mailto:[EMAIL PROTECTED] 
]

Sent: Wednesday, December 10, 2008 3:24 PM
To: dspace-tech@lists.sourceforge.net
Cc: Smail, James W. (LARC-B702)[NCI INFORMATION SYSTEMS]
Subject: [Dspace-tech] "Cleanup" cron question

 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 de

Re: [Dspace-tech] "Cleanup" cron question

2008-12-10 Thread Thornton, Susan M. (LARC-B702)[NCI INFORMATION SYSTEMS]

I think that's the root of the problem, however when I run a query to
update all bundle.primary_bitstream_id to 0, here's what I get:

ERROR:  insert or update on table "bundle" violates foreign key
constraint "$2"
DETAIL:  Key (primary_bitstream_id)=(0) is not present in table
"bitstream".

-Original Message-
From: Brian Freels-Stendel [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 10, 2008 3:53 PM
To: dspace-tech@lists.sourceforge.net; Thornton, Susan M.
(LARC-B702)[NCI INFORMATION SYSTEMS]
Subject: RE: [Dspace-tech] "Cleanup" cron question

It seems to me I've seen that the primary_bitstream_id and the
mets_bitstream_id are both unused fields, and should be Null.  Is that
wrong?

I toyed with the idea of setting my few values to Null, but thought
better of it before finding out exactly why some are getting updated.

B--

>>> On 12/10/2008 at 1:45 PM, in message
<[EMAIL PROTECTED]>,
"Thornton,
Susan M. (LARC-B702)[NCI INFORMATION SYSTEMS]"
<[EMAIL PROTECTED]>
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

Re: [Dspace-tech] "Cleanup" cron question

2008-12-10 Thread Thornton, Susan M. (LARC-B702)[NCI INFORMATION SYSTEMS]

Wow!  I just answered my own question, thanks to an idea I got from
Brian's reply to my question ("It seems to me I've seen that the
primary_bitstream_id and the mets_bitstream_id are both unused fields,
and should be Null."...:-)  Yes, the cleanup job DOES physically delete
all the rows in the bitstream table where "deleted is true".  I ran the
following SQL query to correct the relational integrity problems between
the bundle and bitstream tables:

 

UPDATE bundle 

   SET primary_bitstream_id = NULL 

WHERE primary_bitstream_id > 0

 

Once I ran this query (it updated 7 rows in the bundle table), I was
able to get "cleanup" to run to successful completion, and YES - it
deleted all those rows in the bitstream table that were "marked" for
deletion.

 

For those of you who either don't have this problem or don't KNOW you
have this problem, look in dspace.log after your "cleanup" job runs.
You may see something like:

 

2008-12-10 15:19:00,921 FATAL org.dspace.storage.bitstore.Cleanup @
Caught exception:

org.postgresql.util.PSQLException: ERROR: update or delete on table
"bitstream" violates foreign key constraint "$2" on table "bundle"

  Detail: Key (bitstream_id)=(43213) is still referenced from table
"bundle".

at
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecu
torImpl.java:1592)

at
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImp
l.java:1327)

at
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:
193)

at
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Stateme
nt.java:452)

at
org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdb
c2Statement.java:351)

at
org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2S
tatement.java:305)

at
org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(Delega
tingPreparedStatement.java:101)

at
org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(Delega
tingPreparedStatement.java:101)

at
org.dspace.storage.rdbms.DatabaseManager.updateQuery(DatabaseManager.jav
a:519)

at
org.dspace.storage.rdbms.DatabaseManager.updateQuery(DatabaseManager.jav
a:547)

at
org.dspace.storage.rdbms.DatabaseManager.deleteByValue(DatabaseManager.j
ava:702)

at
org.dspace.storage.rdbms.DatabaseManager.delete(DatabaseManager.java:669
)

at
org.dspace.storage.bitstore.BitstreamStorageManager.cleanup(BitstreamSto
rageManager.java:663)

at
org.dspace.storage.bitstore.Cleanup.main(Cleanup.java:109)

 

 

The reason why you may not know you have the problem is because the
cleanup cron does not check for return code after executing.  I just
happened to notice the above error in dspace.log one day and, after
adding the following code to the cleanup cron, I began to see that
cleanup never completed successfully:






# Shell script for cleaning the asset store.

 

# Get the DSPACE/bin directory

BINDIR=`dirname $0`

 

echo "Cleaning the asset store"

 

$BINDIR/dsrun org.dspace.storage.bitstore.Cleanup

 



# Check to see if the program executed successfully

if [ "$?" -ne "0" ]; then

   echo "cleanup cron failed"

   exit 1

fi

 

echo "cleanup cron completed successfully!"

exit 0


*

 

Thanks to everyone who responded to my post!

Happy Holidays!!

Sue

 



From: Thornton, Susan M. (LARC-B702)[NCI INFORMATION SYSTEMS]
[mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 10, 2008 3:24 PM
To: dspace-tech@lists.sourceforge.net
Cc: Smail, James W. (LARC-B702)[NCI INFORMATION SYSTEMS]
Subject: [Dspace-tech] "Cleanup" cron question

 

 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 c

Re: [Dspace-tech] "Cleanup" cron question

2008-12-10 Thread Diggory Mark

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

Re: [Dspace-tech] "Cleanup" cron question

2008-12-10 Thread Brian Freels-Stendel

It seems to me I've seen that the primary_bitstream_id and the 
mets_bitstream_id are both unused fields, and should be Null.  Is that wrong?

I toyed with the idea of setting my few values to Null, but thought better of 
it before finding out exactly why some are getting updated.

B--

>>> On 12/10/2008 at 1:45 PM, in message
<[EMAIL PROTECTED]>, "Thornton,
Susan M. (LARC-B702)[NCI INFORMATION SYSTEMS]" <[EMAIL PROTECTED]>
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

Re: [Dspace-tech] "Cleanup" cron question

2008-12-10 Thread Thornton, Susan M. (LARC-B702)[NCI INFORMATION SYSTEMS]

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

Re: [Dspace-tech] "Cleanup" cron question

2008-12-10 Thread Brian Freels-Stendel

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]  
> 
>  


--
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

Re: [Dspace-tech] "Cleanup" cron question

Re: [Dspace-tech] "Cleanup" cron question

Re: [Dspace-tech] "Cleanup" cron question

Re: [Dspace-tech] "Cleanup" cron question

Re: [Dspace-tech] "Cleanup" cron question

Re: [Dspace-tech] "Cleanup" cron question

Re: [Dspace-tech] "Cleanup" cron question

Re: [Dspace-tech] "Cleanup" cron question

8 matches

Site Navigation

Mail list logo

Footer information