I have need of a decimal data type–well actually a monetary data type, but I figured I needed to figure out the decimal part first.
I have installed the Data Type RDF module, as well as the Numeric Data Types module, but neither has the option immediately apparent. Since the RDF Datatype module had it and the the Data Type RDF and Numeric Data Types modules were supposed to be an upgrade, I’m sure that the capability is buried in there somewhere, I just don’t know how to do it. Can somebody tell me please?
I looked for this too, but it’s currently not available. There is a GitHub issue for Measurements but it’s never been implemented. We’re currently making do with just a text field, but if I can find time in the dev budget might try an implementation myself.
No, we couldn’t just copy it. It’s not that straightforward. At a minimum it would require a comprehensive analysis, a code refactor, and intensive testing. More realistically we would glean what ideas we could from the deprecated module, and then develop a new data type, following the specific patterns required by NumericDataTypes.
I had a quick look at the RDF Datatypes, and that was something of a fudge. It just took a text field input, checked it was a number, saved it as text, and set the type to rdf:decimal. It doesn’t appear to support faceted browsing or comparison between values, etc.
We’d want something better than that with a proper input widget, full validation, and full search operators. The real underlying problem to solve is how to store in a way that doesn’t lose any precision but still allows fast search comparisons to be made, and that’s before you even start thinking about measurement types and normalisation of base values for comparisons.
My initial thoughts was largely to clone the current Integer implementation, with a new table for numeric_data_types_decimal with a decimal type field for the value. The question there is what precision and scale to set and the implications that has for storage size and speed, etc. The maximum of DECIMAL(65,30) in MySQL would allow for 65 digits up to 30 decimal places. I suspect that would be enough for most purposes, or we could reduce that to something more sensible? I think there are other options for storage, e.g. value and precision as bigints, but this is the simplest and fastest for doing comparisons directly in SQL and may avoid the need for special libraries or classes to handle the maths otherwise.