Ticket #61 (defect)
Opened 7 years ago
Last modified 7 years ago
Decimal, long, and fixedpoint should support arbitrary precision and scale
Status: closed (fixed)
| Reported by: | fumanchu | Assigned to: | fumanchu |
|---|---|---|---|
| Priority: | major | Milestone: | 1.5 |
| Component: | Storage | Keywords: | |
| Cc: | Estimate (total hours): | 4 | |
In most of the DB storage managers, float, decimal, and fixedpoint UnitProperty? values are currently limited to the max precision, scale, or bytes of the underlying DB's numeric columns. These should all support arbitrary values via TEXT columns when outside of acceptable limits. If the UnitProperty? in question doesn't have specified precision, scale, or bytes hints, then we should default to numeric_max_precision, etc. But if these are explicitly set to a large number (or 0 to mean no limit), then we should create TEXT columns to accomodate this.
Change History
07/13/06 03:18:09: Modified by fumanchu
07/24/06 16:30:15: Modified by fumanchu
- status changed from assigned to closed.
- resolution set to fixed.
- summary changed from Decimal, float, and fixedpoint should support arbitrary precision and scale to Decimal, long, and fixedpoint should support arbitrary precision and scale.
Fixed in [236]. The long, fixedpoint, and decimal types may now all be stored at arbitrary precision and scale; most DB's will use TEXT when their builtin numeric types overflow. Note that, because Python's float type is limited to 53 binary digits (on most platforms), it doesn't have the same freedom, and maps to most DB's DOUBLE PRECISION anyway.
Added new tests and refactored support for a range of precision and scale for the db and all stores in [223]. This does not yet include arbitrary precision; that would require TEXT columns which would require the SQL decompiler to know the database datatype for each column (so it could detect e.g. numeric-to-text comparisons and flag them as imperfect/cannot_represent). That would require the SM to inspect column datatypes before any SQL is written, especially to support the case where the database came first and the Dejavu model came after. And all of that is big enough to warrant its own ticket: #62.