sqlobject-discuss

[SQLObject] problem: implementing BoolCol

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

Ian and all,

I tried to implement BoolCol and have the following problem:

The function sqlRepr in SQLBuilder.py should cast boolean values to
either 't' or 'f'  (or some alternative reps).  Problem is that (in
Python 2.2 that I use), there is no Boolean type and sqlRepr has only
the python type of the (value) object and knows nothing about the
related ColType (SQL type).  So I can't figure out how to recognize
that I deal with a boolean in sqlRepr...  

Would it be worth while to refactor sqlRepr to get a second argument
that specifies the desired SQL type?

cheers

--b




/-----------------------------------------------------------------
| Bud P. Bruegger, Ph.D. 
| Sistema (www.sistema.it)
| Via U. Bassi, 54
| 58100 Grosseto, Italy
| +39-0564-411682 (voice and fax)
\-----------------------------------------------------------------

Re: [SQLObject] problem: implementing BoolCol

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

On Mon, 2003-04-14 at 10:53, Bud P.Bruegger wrote:
> I tried to implement BoolCol and have the following problem:
> 
> The function sqlRepr in SQLBuilder.py should cast boolean values to
> either 't' or 'f'  (or some alternative reps).  Problem is that (in
> Python 2.2 that I use), there is no Boolean type and sqlRepr has only
> the python type of the (value) object and knows nothing about the
> related ColType (SQL type).  So I can't figure out how to recognize
> that I deal with a boolean in sqlRepr...  
> 
> Would it be worth while to refactor sqlRepr to get a second argument
> that specifies the desired SQL type?

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

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

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