[
http://jira.dspace.org/jira/browse/DS-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Donohue updated DS-494:
---------------------------
Affects Version/s: 1.6.0
1.5.2
Fix Version/s: (was: 1.6.0)
(was: 1.5.2)
1.6.1
>From discussion during DSpace Developers Mtg on Feb 17 2010 (
>http://www.duraspace.org/irclogs/index.php?date=2010-02-17 )
This issue needs some more eyes on it! It's recommended for post-1.6.0, but we
need more testers to ensure that there are not deeper problems here.
[16:37] <tdonohue> http://jira.dspace.org/jira/browse/DS-494 :
DatabaseManager.process() unnecessarily limits range of DECIMAL or NUMERIC
[16:38] <tdonohue> (last, but not least!)
[16:38] <tdonohue> mhwood: so, this is not meant for 1.6.0, right. Just
something to resolve for 1.6.1? Or is it causing big issues?
[16:38] <mhwood> I'm nervous about changing something so deep in the core of
what DSpace does. No, I would recommend against putting it in 1.6.0
[16:39] <tdonohue> ok. This sounds like a good fix to me, but I'd also vote
post-1.6.0. Needs more eyes on it, more testing from both Oracle & PostgreSQL
folks
[16:39] <mhwood> I don't know of another case where this causes problems, but
it looks incorrect as is.
[16:40] <mhwood> Yes, more eyes please.
[16:40] <tdonohue> Ok. sounds good.
> DatabaseManager.process() unnecessarily limits range of DECIMAL or NUMERIC
> --------------------------------------------------------------------------
>
> Key: DS-494
> URL: http://jira.dspace.org/jira/browse/DS-494
> Project: DSpace 1.x
> Issue Type: Bug
> Components: DSpace API
> Affects Versions: 1.5.2, 1.6.0
> Environment: PostgreSQL
> Reporter: Mark Wood
> Assignee: Mark Wood
> Priority: Minor
> Fix For: 1.6.1
>
> Attachments: DatabaseManager.patch
>
>
> INTEGER, DECIMAL, and NUMERIC are lumped together. In the case we are using
> Oracle, the code will set the column to an int or a long depending on the
> size of the value. (I would like to know why we bother.) Otherwise the
> value is assumed to be within the range of int. But DECIMAL and NUMERIC can
> be far larger than int, and are returned by e.g. sum(BIGINT).
> The attached patch widens the result, in the non-Oracle case, to long for all
> three SQL datatypes. Strictly speaking, DECIMAL and NUMERIC should be mapped
> to java.math.BigDecimal, but that requires the introduction of new methods to
> TableRow as well. Widening from int to long probably covers most of the
> real-world cases. The patch is against 1.5.2 but also applies to 1.6.0-rc2.
> I would appreciate comments on how this widening may affect other code. The
> patch is in test on a live system, but in a locally-developed webapp rather
> than any of the main DSpace UIs.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.dspace.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
