To check the data types available start a Python terminal, import dabo and then type either of the following type commands to see the options. These are used in the bizobj code when defining the DataStructure?.
>>> import dabo
'/usr/lib/python2.4/site-packages/dabo' not versioned, and not exported
>>> print dabo.db.daboTypes
{'C': <type 'unicode'>, 'B': <type 'bool'>, 'D': <type 'datetime.date'>,
'G': <type 'long'>, 'F': <type 'float'>, 'I': <type 'int'>, 'M': <type 'unicode'>,
'L': <type 'str'>, 'N': <class 'decimal.Decimal'>, 'T': <type 'datetime.datetime'>}
>>> print dabo.db.pythonTypes
{<type 'unicode'>: 'C', <type 'bool'>: 'B', <type 'str'>: 'C', <class 'decimal.Decimal'>: 'N',
<type 'float'>: 'F', <type 'int'>: 'I', <type 'datetime.date'>: 'D', <type 'long'>: 'G',
<type 'datetime.datetime'>: 'T'}
dabo is using G for long.
there is no L in either of the list
Turns out some of the db modules use buffer, some use array.array, some use str to represent blobs. I just made "L" map to str, as Python's str object can handle any-length binary data just fine.
Here is an example (excerpt) of where the dabo data type has been used in bizobj code:
# Setting the DataStructure explicitly here is optional, but recommended asThe first value in each tuple is the field name. The second value of each tuple is the dabo data type.
# it will keep Dabo from interpreting field types from the backend every
# time. It lets you specify what types you expect which fields to be. Also,
# this information is used in self.setSQL() to add the fields to the query.
# (field_alias, field_type, pk, table_name, field_name, field_scale)
self.DataStructure = (
("id", "I", True, "reccats", "id"),
("descrp", "C", False, "reccats", "descrp"),
("html", "M", False, "reccats", "html"),
("image", "C", False, "reccats", "image"),
)