Relational databases (what most people would think of as an SQL database) store data in tables, where the a table contains columns each of which has a type (such as integer or varchar). Rekall maps these onto a set of internal types when data is read from a table, and back again when the data in a a table is updated. The table below is a list of these types:
Rekall Type | Usage |
Integer | Used for whole numbers, like 42 or 1066. This is represented by the hardware's natural integer value, so will almost certainly be a signed 32-bit number, which has a range of around plus-or-minus 2 billion (2000000000). |
Float | Used for numbers with decimal points. Again, this is handled using the hardware's natural long floating point representation; almost certainly 64 bits. Note that Rekall does not currently have any specific internal support for fixed point numbers. |
Date | This type holds a date, ie., a year, a month and a day. Valid dates start with the introduction of the Gregorian calendar in England (in 1752), and far as Rekall is concerned, the universe ends around 8000AD. If you database ceases to work after this date, you are welcome to notify us! |
Time | Contains a time, ie., hours, minutes and seconds. |
DateTime | Combines date and time. |
String | This type is used to handle values that are returned from the database as strings of text characters. Typically these are things that can be thought of a printable, although there is no specific requirement for this. Also, strings are not required to be null-terminated (although life is often easier if they are). There are no length restrictions. |
Binary | The binary type is rather like the string type, but is used for data which is typically not thought of as printable, for instance images. Again, there are no length restrictions (other than the usual things like availability of memory). |
Boolean | True or false. This is an explicit truth value, although other types can interpreted as true or false (for instance non-zero numbers are true, and strings are converted to numbers). |
When Rekall accesses a table in a server database, it identifies the type of each column retrieved (or, in general, each expression that it retrieves, this being relevant in forms and reports) and maps the server database type to one of the above internal types. The exact mapping depends on the particular server database (and the database driver that interfaces Rekall to the server database), but the table below shows typical mappings for common SQL types (both SQL92/SQL3 types and some server database specific types):
Rekall Type | SQL Types |
Integer | smallint, int, integer |
Float | float(p), real, double precision |
Date | date |
Time | time |
DateTime | timestamp |
String | char(n), varchar(n) |
Binary | blob |
Boolean | boolean, logical |
In addition, Rekall defines two pseudo-types, Primary Key and Foreign Key. The first is the type that Rekall thinks is the most appropriate type for a primary key column, for instance for MySQL this is a (32 bit) integer column which is marked with the MySQL primary key and auto-increment attributes. The second is similarly for a foreign key, and is typically a (32 bit) non-null integer. This type is useful if you are not especially bothered about the type used for primary keys, and are happy to let Rekall make the decision for you ( These types are particularly useful with XBase, which has no notion of primary keys. The Rekall XBase driver handles primary keys by creating a 22 character column, and generates values that are almost certain to be unique. A foreign key also becomes a 22 character column. Note that for this to work, the primary key column must be the first column in the table. )
Some server databases offer server-specific types. PostgreSQL is a notable example, having types for such things as geometric objects (points, line segements, and so forth) and computer networking (such as internet addresses). Rekall will generally treat these as String values, passing back values retrieved from the server database exactly as they are returned by the database select query. Similarly, when one of these values is updated in a table, the text string is passed as part of the update query.
Rekall will do its best to check values internally, for instance if it knows that a column contains an integer, it will ensure that only digits can be entered. This means that errors are detected and reported quite early on. However, in the case of any server-specific types, such checking is not done ( In fact, such checking could be done, since Rekall contains mechanisms to pass driver-specific type information around with data values. However, this is not currently used for type checking. ) so errors will only be reported as and when the server database reports and error when a query is presented to it. For instance, PostgreSQL will accept a point value in the format (10,20), but Rekall will not prevent you from entering (10.20), and an error will not be reported until Rekall tries to update the table. There is a way around this since input fields in forms can have arbitrary validation expressions associated with them, and you can also associate validation expressions with table columns (as explained below), but you will have to do this yourself.