| java.lang.Object
 simpleorm.properties.SPropertyMap
simpleorm.core.SFieldMeta
simpleorm.core.SFieldScalar
simpleorm.core.SFieldBigDecimal
| SFieldBigDecimal | | public class SFieldBigDecimal extends SFieldScalar (Code) | | Represents BigDecimal field meta data. Default SQL type is
NUMERIC(precission, scale), which is roughly sql-92.
What is the best way to represent money ammounts exactly? Scaled
longs are no good for direct end user queries on the database.
Doubles tend to loose precission due to Java truncating instead of
rounding -- things will not balance. And BigDecimals are
inefficient and a real pain to use. Your choice.
|
| Constructor Summary | |
| public | SFieldBigDecimal(SRecordMeta meta, String columnName, int precission, int scale, SPropertyValue[] pvals)
Note that precission and scale parameters only affect how the
tables are created. | | public | SFieldBigDecimal(SRecordMeta meta, String columnName, int precission, int scale)
| | public | SFieldBigDecimal(SRecordMeta meta, String columnName, int precission, int scale, SPropertyValue pval)
| | public | SFieldBigDecimal(SRecordMeta meta, String columnName, int precission, int scale, SPropertyValue pval1, SPropertyValue pval2)
|
| SFieldBigDecimal | | public SFieldBigDecimal(SRecordMeta meta, String columnName, int precission, int scale, SPropertyValue[] pvals)(Code) | | Note that precission and scale parameters only affect how the
tables are created. The scale that is actually returned is up
to JDBC. And then you are responsible for dealing with rounding
issues.
|
| defaultDataType | | String defaultDataType()(Code) | | Specializes SFieldMeta. This is basically SQL 2, and fairly
database independent, we hope. Note that "BIGDECIMAL" for Oracle
means a text field that can contain over 2K characters!
|
|
|