Developers Manual 1.20
|
|
|
4. Customising ReStore for Individual Databases
4.2 Datatypes
The main way in which databases diverge from standards and from each other is in the names and restrictions they place on the different datatypes, and the actual datatypes they make available. The first step in creating a configuration method is to define these datatypes - this allows ReStore to take class definition methods and create correct database schemas.
An instance of SSWSQLDialect stores its primary datatype configuration as a Dictionary in the instance variable datatypes. This maps symbols (giving a common grammar to the datatypes) to a String denoting the name given to that datatype by the database. The default configuration is as follows:
Description Equivalent Class Dictionary Key Default Value Other Possible Values
(not definitive)Fixed-size String String fixedSize: #char CHAR(%1) CHARACTER Variable-sized String String maxSize: #varchar VARCHAR(%1) VARCHAR2 Unlimited String String #longText LONGTEXT TEXT, MEMO, CLOB Integer Integer #integer INTEGER NUMBER Single Float not used by any class at present #singleFloat FLOAT REAL, IEEESINGLE Double Float Float #doubleFloat DOUBLE IEEEDOUBLE Boolean Boolean (True/False) #boolean BOOLEAN YESNO, TINYINT Scaled Decimal ScaledDecimal withPrecision:scale: #decimal DECIMAL(%1,%2) NUMERIC, MONEY Timestamp (Date & Time) TimeStamp #timestamp TIMESTAMP DATETIME, DATE Date (only) Date #date - DATE Time (only) Time #time - TIME Configuring your database's datatypes primarily consists of replacing the default value with the particular name given by your database to that type. It is worth noting that some databases accept pseudonymns for some types, and so two or more different words may actually specify the same type.
String Types
For an introduction to the issues surrounding Strings in databases, please see earlier. The first thing to note here is that the '%1' in the Default Value is a placeholder for a parameter - this is substituted with the size value from the parameterised class.As was noted earlier, some databases place restrictions on the use of unlimited (#longText) Strings. To help overcome these, SSWSQLDialect provides for further String-related configuration with the following instance variables:
maxChar
maxVarchar
defaultStringSize
maxChar and maxVarchar are largely self-explanatory, as they define the maximum-permisible size of a column of that type. If a class definition specifies a fixed or variable sized String greater than this, an 'unlimited' sized String is substituted.
The function of defaultStringSize is also to an extent self-explanatory, defining the default size that an 'unlimited' sized String is assumed to be. However it also has a more important purpose. By default, the value of maxChar and maxVarchar is 255 characters (the usual limits for most databases), and defaultStringSize is 2048. This configuration causes an instance variable specified as an 'unlimited' String (i.e. without a given size) to map to a #longText column in the database.
If, however, defaultStringSize is the same or less than maxVarchar, then an instance variable specified as an 'unlimited' String will by default map to a #varchar column in the database. This behaviour is useful for some databases which allow only one #longText column per table. Of course, you can still force the use of a #longText by explicitly specifying a String of greater size than maxVarchar.
If your database does not support an equivalent to the #longText column type at all, then you should remove the #longText key from the datatypes Dictionary - this will cause all unlimited Strings, or Strings with a specified size greater than maxVarchar, to map to a #varchar column with the maximum-permitted size.
Boolean
If your chosen database does not offer an explicit BOOLEAN type, then select the smallest-sized INTEGER column type - e.g. SMALLINT or TINYINT.ScaledDecimal
Similar to the String types, ScaledDecimal is represent by a parameterised class in class specification methods. This is handled in the equivalent database type by the use of parameter placeholders, %1 representing the precision parameter and %2 representing the scale parameter.Dates and Times
Databases differ not only in their names for Date and Time types, but also in which types they actually support. The most conservative implementation (that assumed by the standard configuration) is that only a single, combined type (a timestamp) is supported. In this case, if an instance variable is specified as Date or Time, a #timestamp column will be used - however ReStore will automatically convert to and from this so that, as far as the application code is concerned, a Date or Time alone is held.If your database additionally supports individual DATE and TIME column types, then you can specify that these are used directly by placing their names in the datatypes Dictionary at the keys #date and #time respectively.
4. Customising ReStore for Individual Databases