Re: [SQLObject] problem: implementing BoolCol

[Bud P. B. <bu...@si...>]

On 16 Apr 2003 16:15:25 -0500
Ian Bicking <ia...@co...> wrote:

....
> 
> Yes, that is a problem.  In the meantime you can override the accessor
> directly.  Ultimately the Constraints system will handle this, as I'm
> going to expand it to also do some sort of conversion.  You'll have
> something like:
> 
> class AsBool(Validator):
>     def convertSQL(self, value):
>         return ["'f'", "'t'"][not not value]
>     def unconvertSQL(self, value):
>         return value == 'f'
> 
> (Assuming you also get 't'/'f' back, but maybe I'm wrong)
> 
>   Ian

From what I understand, the above may not be sufficient.  My current
misunderstanding is that the conversion to and from sql depends on
three parameters:

* the type/class of the object instance
* the desired SQL type  (there are several possible implementation
  decisions for a single python type, it seems)
* the actual DBI module:  I looked a little further into psycopg and it seems
  they do some interesting things including type casting that requires
  registration of classes etc.  That seems very dependent on which
  DBI module one uses (note that there are several for PostgreSQL).  

I believe ultimately it would be nice to have a single mechanism that
is used for both "built-in" types as well as for user defined types.
This is where type casting (probably a better term for what I called
"higher level types") can come in.  Psycopg already seems to do most
of this that could directly be used--but I have to look into this a
little closer..  

For the time being, it seems that a lot can be done by overwriting the
_get_xxx and _set_xxx methods as you indicate in your other message.
Just that user defined types would make it much more eligant and
manageable...

cheers

--bud