Re: [SQLObject] problem: implementing BoolCol

[Ian B. <ia...@co...>]

On Thu, 2003-04-17 at 10:47, Bud P.Bruegger wrote:
> > class AsBool(Validator):
> >     def convertSQL(self, value):
> >         return ["'f'", "'t'"][not not value]
> >     def unconvertSQL(self, value):
> >         return value == 'f'
> 
> >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 validator can take arguments in its __init__, which could be used to
specialize it more fully.

> * the desired SQL type  (there are several possible implementation
>   decisions for a single python type, it seems)

This gets folded in.  For instance, I would expect a BoolCol to add a
AsBool validator automatically.

> * 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).  

Yes... this would probably not work together with psycopg, but function
instead of psycopg in this case.  At least, so long as there is a
neutral way psycopg can handle Postgres objects.

> 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..  

Hmm... yes, typecasting is another way of looking at this.  I'm still
not firm on how the validator stuff is going to work... maybe thinking
in terms of typecasting would be better than conversion.  Of course the
types involved aren't actually Python types -- they are foreign types
that are not properly typed in Python, and changing those into Python
types (or vice versa).

> 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...

Indeed.  The hooks are there specifically for this case, but it
certainly could be more elegant.

  Ian