Please sign in to comment.
Consider number/numeric/decimal columns with a 0 scale to be integer …
…columns (e.g. numeric(10, 0)) This actually fixes two separate issues. The simple one was that the column type NUMBER was not recognized. Oracle apparently uses this type for numeric values. The second issue was that previously Sequel always treated numeric and decimal columns as decimals, so the model typecasting code uses the ruby type BigDecimal. However, if the scale of such a column is 0, it's really storing just an arbitrary sized integer as opposed to a true decimal value. Since ruby's integers already support arbitrarily large values, it makes sense to typecast the values for such columns to integer instead of decimal. The generic handling of this is fairly clean, with a single override in Database#schema_column_type. However, some adapters such as the JDBC and shared MSSQL adapter use :scale options instead of including the scale in the :db_type option, and for those adding this behavior is fairly ugly. I choose to copy the approach the JDBC adapter used to the shared MSSQL adapter, but if more adapters need it in the future, I'll probably refactor to make the support more generic. While working on this I discovered that if you use BigDecimal or Numeric as a column type in Sequel, and you don't provide a :size option as a two element array, most databases will assume a scale of 0 (thus creating an integer-like column), since that's what the SQL standard specifies. PostgreSQL doesn't do that, though, so if you don't provide a :size option on PostgreSQL, it operates as a real decimal field instead of an integer-like field.
- Loading branch information...
Showing with 30 additions and 8 deletions.