Gary,
Thanks, but that script does two things. (1) it pretty much answers my
original question that that handle prefix is only in the Oracle database, and
(2) it explicitly says that is it "Currently only compatible with installs
running a PostgreSQL database" which pretty much means I've got to directly
modify the Oracle db.
However, that is precisely what I needed to know, so Thanks Much.
Brian A. Helstien, SISD, MLS,
Director, Special Technologies Initiatives,
IDM, University Libraries x06913
University of Southern California, (213) 740-6913
Los Angeles, California, 90089 [EMAIL PROTECTED]
Information is independent of media or format
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Thursday, October 25, 2007 3:24 AM
To: [email protected]
Subject: DSpace-tech Digest, Vol 18, Issue 37
Send DSpace-tech mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/dspace-tech
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific than "Re:
Contents of DSpace-tech digest..."
Today's Topics:
1. Re: "Reverse" Dspace Instance Migration question
(Christian Voelker)
2. Re: "Reverse" Dspace Instance Migration question (Brian Helstien)
3. Re: "Reverse" Dspace Instance Migration question (Gary Browne)
4. Re: Browse access very slow (James Rutherford)
5. Re: "Reverse" Dspace Instance Migration question
(Jayan Chirayath Kurian)
----------------------------------------------------------------------
Message: 1
Date: Thu, 25 Oct 2007 01:05:13 +0200
From: Christian Voelker <[EMAIL PROTECTED]>
Subject: Re: [Dspace-tech] "Reverse" Dspace Instance Migration
question
To: Brian Helstien <[EMAIL PROTECTED]>
Cc: "'[email protected]'"
<[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Am 24.10.2007 um 23:57 schrieb Brian Helstien:
> I'm currently running Dspace 1.3.2/Oracle/Solaris 9/ on my production
> server.
>
> I want to conduct an upgrade to 1.4.2.
> I successfully upgraded my test server to 1.4.2.
...
> I dropped entirely my Oracle database on my test server, exported the
> production db into test, and then tarred and moved /dspace_source and
> /dspace directories onto test.
> I've edited my dspace.cfg to point to the test Oracle db and the test
> server, updated my wars and started Tomcat
...
> I have changed both the dspace.cfg handle number and the handle
> config.dct files to represent my test server handle.
> How do I change the just the handle prefix number associated with the
> entries. I've seen the entry regarding migrating data from test to
> production entry on the wiki and isn't what I need. How do I change
> the just the handle prefix number associated with the entries.
...
> Do I just need to modify all the prefix numbers in the Oracle db or is
> this handle value stored elsewhere?
As far as I know, the handle prefix is in the files you told and the only place
for handles is in one table in the db. There is a script that comes with DSpace
to do what you want to do. I think that this is what you think is not the right
thing for you, but I suggest that you take a second look. I think this script
does not touch the second half of your handles (behind the slash) but changes
only the prefix in all database entries.
Besides, I dont understand exactly why your handles would have changed unless
you created new items during testing.
Depending on what you did exactly when exporting your production db to test
(e.g. dump production and run the dump on the test machine, then running the
sql upgrade script), the database should still contain all valid handles
unaltered. The settings in dspace.cfg apply to new items only and the
config.dct change made sure that your test server did not answer external
resolution requests, thats all.
If you are not sure, I would block the production system for write access and
do the same steps you did for testing once more, with a snapshot of the latest
production data- base, then switch to the new machine. I would move only the
/dspace dir containing the assetstore, but not /dspace_source.
You have your 1.4.2 sources already there. If you have to merge local changes,
then you have to do that in advance and this will be the largest task of your
migration.
I would use a local cvs or svn repository to simplify that step ( I actually
did it that way already).
I would use the new config files as a template and merge with the values of the
old configs. For the handle server, I would do the same, as there was a fix in
the configuration script for 1.4 that did not make it backwards to 1.3.2.
I guess that you did not notice this since you did not try with your proper
handle prefix. If you run into this, then you will notice it because your
handle server just wont start.
You can increment the version which is not the software version of the handle
server but the version of your local service. You can and *should* copy the key
files unaltered.
as of my understanding. Thats it.
Bye, Christian
------------------------------
Message: 2
Date: Wed, 24 Oct 2007 18:41:14 -0700
From: Brian Helstien <[EMAIL PROTECTED]>
Subject: Re: [Dspace-tech] "Reverse" Dspace Instance Migration
question
To: 'Christian Voelker' <[EMAIL PROTECTED]>
Cc: "'[email protected]'"
<[email protected]>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
Christian,
Which script? Please, give me the name.
Brian A. Helstien, SISD, MLS,
Director, Special Technologies Initiatives,
IDM, University Libraries x06913
University of Southern California, (213) 740-6913
Los Angeles, California, 90089 [EMAIL PROTECTED]
Information is independent of media or format
-----Original Message-----
From: Christian Voelker [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 24, 2007 4:05 PM
To: Brian Helstien
Cc: '[email protected]'
Subject: Re: [Dspace-tech] "Reverse" Dspace Instance Migration question
Am 24.10.2007 um 23:57 schrieb Brian Helstien:
> I'm currently running Dspace 1.3.2/Oracle/Solaris 9/ on my production
> server.
>
> I want to conduct an upgrade to 1.4.2.
> I successfully upgraded my test server to 1.4.2.
...
> I dropped entirely my Oracle database on my test server, exported the
> production db into test, and then tarred and moved /dspace_source and
> /dspace directories onto test.
> I've edited my dspace.cfg to point to the test Oracle db and the test
> server, updated my wars and started Tomcat
...
> I have changed both the dspace.cfg handle number and the handle
> config.dct files to represent my test server handle.
> How do I change the just the handle prefix number associated with the
> entries. I've seen the entry regarding migrating data from test to
> production entry on the wiki and isn't what I need. How do I change
> the just the handle prefix number associated with the entries.
...
> Do I just need to modify all the prefix numbers in the Oracle db or is
> this handle value stored elsewhere?
As far as I know, the handle prefix is in the files you told and the only place
for handles is in one table in the db. There is a script that comes with DSpace
to do what you want to do. I think that this is what you think is not the right
thing for you, but I suggest that you take a second look. I think this script
does not touch the second half of your handles (behind the slash) but changes
only the prefix in all database entries.
Besides, I dont understand exactly why your handles would have changed unless
you created new items during testing.
Depending on what you did exactly when exporting your production db to test
(e.g. dump production and run the dump on the test machine, then running the
sql upgrade script), the database should still contain all valid handles
unaltered. The settings in dspace.cfg apply to new items only and the
config.dct change made sure that your test server did not answer external
resolution requests, thats all.
If you are not sure, I would block the production system for write access and
do the same steps you did for testing once more, with a snapshot of the latest
production data- base, then switch to the new machine. I would move only the
/dspace dir containing the assetstore, but not /dspace_source.
You have your 1.4.2 sources already there. If you have to merge local changes,
then you have to do that in advance and this will be the largest task of your
migration.
I would use a local cvs or svn repository to simplify that step ( I actually
did it that way already).
I would use the new config files as a template and merge with the values of the
old configs. For the handle server, I would do the same, as there was a fix in
the configuration script for 1.4 that did not make it backwards to 1.3.2.
I guess that you did not notice this since you did not try with your proper
handle prefix. If you run into this, then you will notice it because your
handle server just wont start.
You can increment the version which is not the software version of the handle
server but the version of your local service. You can and *should* copy the key
files unaltered.
as of my understanding. Thats it.
Bye, Christian
------------------------------
Message: 3
Date: Thu, 25 Oct 2007 17:16:09 +1000
From: "Gary Browne" <[EMAIL PROTECTED]>
Subject: Re: [Dspace-tech] "Reverse" Dspace Instance Migration
question
To: <[email protected]>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
Hi Brian
[dspace]/bin/update-handle-prefix
Gary Browne
Development Programmer
Library IT Services
University of Sydney
ph: 9351-5946
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brian Helstien
Sent: Thursday, 25 October 2007 11:41 AM
To: 'Christian Voelker'
Cc: '[email protected]'
Subject: Re: [Dspace-tech] "Reverse" Dspace Instance Migration question
Christian,
Which script? Please, give me the name.
Brian A. Helstien, SISD, MLS,
Director, Special Technologies Initiatives,
IDM, University Libraries x06913
University of Southern California, (213) 740-6913
Los Angeles, California, 90089 [EMAIL PROTECTED]
Information is independent of media or format
-----Original Message-----
From: Christian Voelker [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 24, 2007 4:05 PM
To: Brian Helstien
Cc: '[email protected]'
Subject: Re: [Dspace-tech] "Reverse" Dspace Instance Migration question
Am 24.10.2007 um 23:57 schrieb Brian Helstien:
> I'm currently running Dspace 1.3.2/Oracle/Solaris 9/ on my production
> server.
>
> I want to conduct an upgrade to 1.4.2.
> I successfully upgraded my test server to 1.4.2.
...
> I dropped entirely my Oracle database on my test server, exported the
> production db into test, and then tarred and moved /dspace_source and
> /dspace directories onto test.
> I've edited my dspace.cfg to point to the test Oracle db and the test
> server, updated my wars and started Tomcat
...
> I have changed both the dspace.cfg handle number and the handle
> config.dct files to represent my test server handle.
> How do I change the just the handle prefix number associated with the
> entries. I've seen the entry regarding migrating data from test to
> production entry on the wiki and isn't what I need. How do I change
> the just the handle prefix number associated with the entries.
...
> Do I just need to modify all the prefix numbers in the Oracle db or is
> this handle value stored elsewhere?
As far as I know, the handle prefix is in the files you told and the only place
for handles is in one table in the db. There is a script that comes with DSpace
to do what you want to do. I think that this is what you think is not the right
thing for you, but I suggest that you take a second look. I think this script
does not touch the second half of your handles (behind the slash) but changes
only the prefix in all database entries.
Besides, I dont understand exactly why your handles would have changed unless
you created new items during testing.
Depending on what you did exactly when exporting your production db to test
(e.g. dump production and run the dump on the test machine, then running the
sql upgrade script), the database should still contain all valid handles
unaltered. The settings in dspace.cfg apply to new items only and the
config.dct change made sure that your test server did not answer external
resolution requests, thats all.
If you are not sure, I would block the production system for write access and
do the same steps you did for testing once more, with a snapshot of the latest
production data- base, then switch to the new machine. I would move only the
/dspace dir containing the assetstore, but not /dspace_source.
You have your 1.4.2 sources already there. If you have to merge local changes,
then you have to do that in advance and this will be the largest task of your
migration.
I would use a local cvs or svn repository to simplify that step ( I actually
did it that way already).
I would use the new config files as a template and merge with the values of the
old configs. For the handle server, I would do the same, as there was a fix in
the configuration script for 1.4 that did not make it backwards to 1.3.2.
I guess that you did not notice this since you did not try with your proper
handle prefix. If you run into this, then you will notice it because your
handle server just wont start.
You can increment the version which is not the software version of the handle
server but the version of your local service. You can and
*should* copy the key files unaltered.
as of my understanding. Thats it.
Bye, Christian
------------------------------------------------------------------------
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
------------------------------
Message: 4
Date: Thu, 25 Oct 2007 10:07:07 +0100
From: James Rutherford <[EMAIL PROTECTED]>
Subject: Re: [Dspace-tech] Browse access very slow
To: Richard Jones <[EMAIL PROTECTED]>
Cc: [email protected], Rafael Henkin
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
On Wed, Oct 24, 2007 at 07:47:20AM +0100, Richard Jones wrote:
> Are you certain that you are using 1.5? We have included in this
> upcoming release a new browse system which removes Browse.java, and
> offers a new configurable way of browsing archive contents. I am
> currently using this over an archive of 125,000 items with no
> noticeable scalability problems, so it seems likely that there is
> something wrong with your set up.
Have you tried this with Manakin? I experienced similar performance problems
(ie: taking ~1 min to browse to a Collection with ~20 items) specifically with
browsing under Manakin. The JSPUI performance was fine.
cheers,
Jim
--
James Rutherford | Hewlett-Packard Limited registered Office:
Research Engineer | Cain Road,
HP Labs | Bracknell,
Bristol, UK | Berks
+44 117 312 7066 | RG12 1HN.
[EMAIL PROTECTED] | Registered No: 690597 England
The contents of this message and any attachments to it are confidential and may
be legally privileged. If you have received this message in error, you should
delete it from your system immediately and advise the sender. To any recipient
of this message within HP, unless otherwise stated you should consider this
message and attachments as "HP CONFIDENTIAL".
------------------------------
Message: 5
Date: Thu, 25 Oct 2007 18:23:29 +0800
From: "Jayan Chirayath Kurian" <[EMAIL PROTECTED]>
Subject: Re: [Dspace-tech] "Reverse" Dspace Instance Migration
question
To: "Brian Helstien" <[EMAIL PROTECTED]>
Cc: [email protected]
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
http://sourceforge.net/tracker/index.php?func=detail&aid=1642563&group_i
d=19984&atid=319984
This was suggested by Stuart and may be of help to you. For me it works fine.
Jayan
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brian Helstien
Sent: Thursday, October 25, 2007 9:41 AM
To: 'Christian Voelker'
Cc: '[email protected]'
Subject: Re: [Dspace-tech] "Reverse" Dspace Instance Migration question
Christian,
Which script? Please, give me the name.
Brian A. Helstien, SISD, MLS,
Director, Special Technologies Initiatives,
IDM, University Libraries x06913
University of Southern California, (213) 740-6913
Los Angeles, California, 90089 [EMAIL PROTECTED]
Information is independent of media or format
-----Original Message-----
From: Christian Voelker [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 24, 2007 4:05 PM
To: Brian Helstien
Cc: '[email protected]'
Subject: Re: [Dspace-tech] "Reverse" Dspace Instance Migration question
Am 24.10.2007 um 23:57 schrieb Brian Helstien:
> I'm currently running Dspace 1.3.2/Oracle/Solaris 9/ on my production
> server.
>
> I want to conduct an upgrade to 1.4.2.
> I successfully upgraded my test server to 1.4.2.
...
> I dropped entirely my Oracle database on my test server, exported the
> production db into test, and then tarred and moved /dspace_source and
> /dspace directories onto test.
> I've edited my dspace.cfg to point to the test Oracle db and the test
> server, updated my wars and started Tomcat
...
> I have changed both the dspace.cfg handle number and the handle
> config.dct files to represent my test server handle.
> How do I change the just the handle prefix number associated with the
> entries. I've seen the entry regarding migrating data from test to
> production entry on the wiki and isn't what I need. How do I change
> the just the handle prefix number associated with the entries.
...
> Do I just need to modify all the prefix numbers in the Oracle db or is
> this handle value stored elsewhere?
As far as I know, the handle prefix is in the files you told and the only place
for handles is in one table in the db. There is a script that comes with DSpace
to do what you want to do. I think that this is what you think is not the right
thing for you, but I suggest that you take a second look. I think this script
does not touch the second half of your handles (behind the slash) but changes
only the prefix in all database entries.
Besides, I dont understand exactly why your handles would have changed unless
you created new items during testing.
Depending on what you did exactly when exporting your production db to test
(e.g. dump production and run the dump on the test machine, then running the
sql upgrade script), the database should still contain all valid handles
unaltered. The settings in dspace.cfg apply to new items only and the
config.dct change made sure that your test server did not answer external
resolution requests, thats all.
If you are not sure, I would block the production system for write access and
do the same steps you did for testing once more, with a snapshot of the latest
production data- base, then switch to the new machine. I would move only the
/dspace dir containing the assetstore, but not /dspace_source.
You have your 1.4.2 sources already there. If you have to merge local changes,
then you have to do that in advance and this will be the largest task of your
migration.
I would use a local cvs or svn repository to simplify that step ( I actually
did it that way already).
I would use the new config files as a template and merge with the values of the
old configs. For the handle server, I would do the same, as there was a fix in
the configuration script for 1.4 that did not make it backwards to 1.3.2.
I guess that you did not notice this since you did not try with your proper
handle prefix. If you run into this, then you will notice it because your
handle server just wont start.
You can increment the version which is not the software version of the handle
server but the version of your local service. You can and
*should* copy the key files unaltered.
as of my understanding. Thats it.
Bye, Christian
------------------------------------------------------------------------
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
------------------------------
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
------------------------------
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
End of DSpace-tech Digest, Vol 18, Issue 37
*******************************************
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
