[
https://jira.duraspace.org/browse/DS-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25189#comment-25189
]
Ivan Masár edited comment on DS-1195 at 6/18/12 8:36 PM:
---------------------------------------------------------
Thank you for your insights, they are very useful.
OAICAT:
I agree with you that when from/until are not specified, OAICat shouldn't make
the assumptions it makes. It should leave such assumption for the application
layer (e.g. in our case DSpace).
"Harvesting is restricted to the range specified by the from and until
arguments, extending back to the earliest datestamp if from is omitted, and
forward to the most recent datestamp if until is omitted."
http://www.openarchives.org/OAI/openarchivesprotocol.html#SelectiveHarvestingandDatestamps
I will file a bug with them and send them a patch removing these assumptions,
but I'm afraid they won't be very responsive. I'll also try to contact
particular authors.
Anyway, we have an alternative to waiting for them to fix it - our OAICat is
pulled from Maven, so we could put the patched version of OAICat in our Maven
repository. However, I don't think this would be a better solution than
applying the workaround in DSpace, because it could mislead someone else who
would try to use org.dspace.oaicat to think it's an unpatched version.
ORACLE:
I understand the OAICat problem, but I still don't completely understand the
Oracle problem. Why doesn't it accept these timestamps? What does timezone have
to do with it? OAI-PMH mandates that all timezones used in the protocol must be
in UTC. But why not convert them for use in the application to the local
timezone?
Would it help to detect local timezone and use it this way?
df.setCalendar(Calendar.getInstance(TimeZone.getTimeZone(localTimezone)));
MANUAL:
This is the easiest thing to change, so if you have anything to put in the
manual, please attach it here.
was (Author: helix84):
Thank you for your insights, they are very useful.
OAICAT:
I agree with you that when from/until are not specified, OAICat shouldn't make
the assumptions it makes. It should leave such assumption for the application
layer (e.g. in our case DSpace).
"Harvesting is restricted to the range specified by the from and until
arguments, extending back to the earliest datestamp if from is omitted, and
forward to the most recent datestamp if until is omitted."
http://www.openarchives.org/OAI/openarchivesprotocol.html#SelectiveHarvestingandDatestamps
I will file a bug with them and send them a patch removing these assumptions,
but I'm afraid they won't be very responsive. I'll also try to contact
particular authors.
Anyway, we have an alternative to waiting for them to fix it - out OAICat is
pulled from Maven, so we could put the patched version of OAICat in our Maven
repository. However, I don't think this would be a better solution than
applying the workaround in DSpace, because it could mislead someone else who
would try to use org.dspace.oaicat to think it's an unpatched version.
ORACLE:
I understand the OAICat problem, but I still don't completely understand the
Oracle problem. Why doesn't it accept these timestamps? What does timezone have
to do with it? OAI-PMH mandates that all timezones used in the protocol must be
in UTC. But why not convert them for use in the application to the local
timezone?
Would it help to detect local timezone and use it this way?
df.setCalendar(Calendar.getInstance(TimeZone.getTimeZone(localTimezone)));
MANUAL:
This is the easiest thing to change, so if you have anything to put in the
manual, please attach it here.
> DSpace OAI with Oracle
> ----------------------
>
> Key: DS-1195
> URL: https://jira.duraspace.org/browse/DS-1195
> Project: DSpace
> Issue Type: Bug
> Components: OAI-PMH
> Affects Versions: 1.8.2
> Environment: Oracle Database
> Reporter: DSpace @ LyNcode
> Priority: Critical
> Attachments: patch-dspace-oai-oracle-db.diff
>
>
> Patch to solve this problem:
> http://sourceforge.net/mailarchive/message.php?msg_id=29421592
> The new OAICAT version does not solve this problem.
> In attachment, you could see a patch to apply over the dspace-oai source:
> $ cd [DSPACE-SOURCE]
> $ patch -p0 < [PATH-TO]/patch-dspace-oai-oracle-db.diff
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
