[
https://jira.duraspace.org/browse/DS-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21198#action_21198
]
Mark H. Wood commented on DS-815:
---------------------------------
I'm definitely coming round to the "raise an exception at construction" POV.
Validation in the UIs would be very nice, but separately it should not be
possible to create a "date" object which is not a date. If a UI wants to throw
away information then it may, but there is no reason for the object not to
provide information in any case, unless that information (in this case, -1 or
an Exception) would cause significant problems. We can improve the UIs later
and the information will already be available when we do.
We probably also want a curation task to ferret out busted "dates" already
lurking in the repository. And to document that certain fields must contain
ISO 8601 dates (to some precision) and nothing else.
Miscellaneous temporal intervals should not be claimed to be "dates". The code
depends on these values to work like dates. If people want to enter "17--" or
"the middle ages" then coverage seems to be the right place for such. I
understand that sometimes the best we have is "written circa 1066" -- if we
want to represent that then DCDdate could (as a separate improvement request)
be augmented with something like setIUncertain(boolean)/isUncertain() and still
compare like a definite date (ignoring the "uncertain" flag but still obeying
granularity).
If someone would like to propose a definite date as the meaning of new
DCDate("") and new DCDate(null) then those could continue to be accepted.
The problem we really have (beyond the NPEs) is that we need certain fields to
be definite dates (to some granularity) for purposes of comparison (browsing,
sorting, filtering) while submitters need to be able to express indefinite or
subject-specific temporal boundaries. Adding decade, century, millennium, and
perhaps era (BCE/CE and the like) granularity to DCDate might help, but values
put into those fields on which we do computations still need to conform to some
syntax that we implement so that they can be compared.
> DCDate throws NullPointerException with mangled dates
> -----------------------------------------------------
>
> Key: DS-815
> URL: https://jira.duraspace.org/browse/DS-815
> Project: DSpace
> Issue Type: Bug
> Components: DSpace API
> Affects Versions: 1.7.0
> Environment: CentOS 5.4 with OpenJDK 64-Bit Server VM (build
> 1.6.0-b09, mixed mode)
> Reporter: Àlex Magaz Graça
> Assignee: Mark H. Wood
> Attachments: DCDate_test_mangled_date.patch
>
>
> DCDate.get*() methods throw a NullPointerException if the object has been
> constructed with a wrong date like "[17--?]" (DCDateTest patch attached):
> java.lang.NullPointerException
> at org.dspace.content.DCDate.getYear(DCDate.java:298)
> at org.dspace.content.DCDateTest.testDCDateString(DCDateTest.java:301)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
> It makes the browse by issue date fail in JSPUI.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.duraspace.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
