Re: [SQLObject] Re: problem: implementing BoolCol

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

On Wed, 2003-04-30 at 12:41, Nick wrote:
> [ earlier discussion about implementing different SQL types and
>   converting them to Python types ]
> 
> I've been looking at the code for Constraints and Col, and it looks to
> me like there needs to be a distiction between real constraints
> (MaxLength, Unique, Not Null, for example) and type checking/casting. 
> It's a little mixed right now.  In terms of type checking and
> conversion, I would propose:
> 
> 1) make validators part of Col instead of just random functions in
> Constraints that get referenced in Col.

Yes, that's possible, i.e., StringCol checks for strings (or maybe calls
str() on Python objects, for instance, or checks the length).  And, I
suppose, you could add new types for specific requirements, like numbers
in a certain range (e.g. IntCol(min=0))

By making column types and validators separate it should be possible to
use richer checks on objects.  

> 2) at the rate it's going, there are going to be a lot of parallel
> _mysql, _postgres, _sqlite, etc. functions for every operation under
> Col.  There needs to be a way to bundle a bunch of functions for the
> particular db api, probably related to whatever _connection type you're
> using.

It's challenging, because there's more than one way things can be built
out -- types may be added over time, or databases may be added.  

> 3) for each db api, there needs to be convert-from-result-to-python and
> convert-from-python-to-sql-value functions as part of the Col class,
> encapsulated by the mechanism described in 2.
> 
> I've got some ideas how to do this, but I don't want to go ripping
> through the code if you're going somewhere else with this.

I've been working on a validation/conversion system for a form
processor.  I'm fairly happy with what I've got, at least for forms, and
it could be applied to SQLObject -- though I wonder if it's too heavy,
since it would be invoked for every get or set of a column.  It makes
composition and definition of validators easier, but maybe that's not as
important for something like SQLObject, where there's a lot more work in
defining an object than just its validators.

Anyway, I'd be interested on some feedback on it.  You can see the
system here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/webware-sandbox/Sandbox/ianbicking/FormEncode/

Validator.py more specifically has the validation code.  Doc strings may
not be up to date (it's based on previous system, and the method names
have been changed -- attemptToPython and attemptFromPython are public
methods) 

  Ian