sqlobject-discuss — All things SQLObject-related

Re: [SQLObject] datetime column conversions

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

Oleg Broytmann wrote:
>>2. Allow the user to set which DateTime he prefers to use, by
>>registering a coercion method. I don't think that this is the same as
>>the validator, though... I assume that this could be done on the class
>>itself, as in:
>>
>>DateTimeCol.DateTime = mx.DateTime.DateTime
> 
> 
>    This is the solution that I'm thinking about. But I think the better
> approach is to create two different subclasses of DateTimeCol (and
> SODateTimeCol) - one for datetime and another for mx.DateTime.

I don't think there should be two classes.  A DateTimeCol isn't actually 
different than an MxDateTimeCol -- they both hold dates, they both look 
the same in the database.  mx.DateTime and datetime should be selected 
with a keyword argument.  Or, maybe it could be configured globally, 
since it's unlikely you'd want to use mx.DateTime in one place and 
datetime somewhere else; but I don't like assigning to a class variable 
like that.  Maybe a class method, 
DateTimeCol.setDefaultImplementation().  In fact, it's just as good if 
it takes a string to indicate which implementation, since their 
interfaces are sufficiently different that you can't deal with the 
module in any abstract way.

-- 
Ian Bicking  /  ia...@co...  / http://blog.ianbicking.org

[SQLObject] Re: datetime column conversions

[Jorge L. G. F. <go...@ie...>]

Oleg Broytmann, Quarta 05 Janeiro 2005 18:58, wrote:

> On Wed, Jan 05, 2005 at 05:41:11PM -0200, Carlos Ribeiro wrote:
>> On IntCol -> int()
>> On FloatCol - > float()
> 
>    I disagree, you know. :)

Hey!  This is my text!  I'm the one who disagrees ;-)

I've been seeing messages on this subject and it seems to me that we are the
only ones kind of reluctant to implement such an automatic conversion.

One thing that I was thinking about was making it optional.  Something like
adding a parameter "auto_cast=False" (default) or "auto_cast=True" when
instantiating the class.  If it is true, then what is read from the
database is passed through a conversion to the type it was supposed to be.

Another option was to add a "cast_method=Method" where the default is
"None".  If it is a method then everything read from the database is passed
to it (where one can make the cast to the desired type with some
'isinstance' checks of the object).  It might be used for other things --
filters come to my mind -- too. 

Who knows both can be implemented if you have time :-)
 
>> 2. Allow the user to set which DateTime he prefers to use, by
>> registering a coercion method. I don't think that this is the same as
>> the validator, though... I assume that this could be done on the class
>> itself, as in:
>> 
>> DateTimeCol.DateTime = mx.DateTime.DateTime
> 
>    This is the solution that I'm thinking about. But I think the better
> approach is to create two different subclasses of DateTimeCol (and
> SODateTimeCol) - one for datetime and another for mx.DateTime.

Hmmm...  maybe making it more generic as a class for the datetime available
on the standard library and another class for external implementations that
provide a minimal interface...  But, then, this might be unnecessary
complexity. 

-- 
Godoy.     <go...@ie...>

Re: [SQLObject] datetime column conversions

[Oleg B. <ph...@ph...>]

On Wed, Jan 05, 2005 at 05:41:11PM -0200, Carlos Ribeiro wrote:
> On IntCol -> int()
> On FloatCol - > float()

   I disagree, you know. :)

> 2. Allow the user to set which DateTime he prefers to use, by
> registering a coercion method. I don't think that this is the same as
> the validator, though... I assume that this could be done on the class
> itself, as in:
> 
> DateTimeCol.DateTime = mx.DateTime.DateTime

   This is the solution that I'm thinking about. But I think the better
approach is to create two different subclasses of DateTimeCol (and
SODateTimeCol) - one for datetime and another for mx.DateTime.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] datetime column conversions

[Carlos R. <car...@gm...>]

On Wed, 5 Jan 2005 21:15:40 +0300, Oleg Broytmann <ph...@ma...> wrote:
> On Wed, Jan 05, 2005 at 01:01:01PM -0500, Barry Warsaw wrote:
> > I'm having one immediate problem though.  I have a DateTimeCol in one of
> > my tables, and I set that column to an instance of a datetime.datetime
> > object.  That's all fine and good because SQLObject turns that into a
> > string and stores it properly in the SQLite database.  However, when I
> > retrieve the column's value, I get a string back, not a datetime.
> 
>    You are just in time! Please look the archive for this mailing list
> and reread messages for the last few days - the discussion about
> string-to-int conversion in the IntCol. Just today I commited a number
> of patches.
> 
>    Your problem is unfortunately a bit harder - what should toPython()
> returns - a string? a datetime instance? a mx.DateTime instance?
> Currently the column returns whatever the underlying driver returns.
> What database and driver do you use?

At the risk of sounding contentious (which I really don't want to),
I'll repeat what I said on that very thread when mentioning Postel's
law. The spirit is, "be strict when sending (to the db), and flexible
when reading (from the db)". I believe that SQLObject could simply
coerce the type to the one the user specified when he/she created the
column object.

On IntCol -> int()
On FloatCol - > float()

Obviously, DateTime presents a different problem because there is a
clash between mx.DateTime and the std DateTime class. But in this
case, one of two workarounds will probably work just as fine:

1. if mx.DateTime is available, use it. If not, use the std library version.

2. Allow the user to set which DateTime he prefers to use, by
registering a coercion method. I don't think that this is the same as
the validator, though... I assume that this could be done on the class
itself, as in:

DateTimeCol.DateTime = mx.DateTime.DateTime

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

Re: [SQLObject] datetime column conversions

[Oleg B. <ph...@ma...>]

On Wed, Jan 05, 2005 at 01:01:01PM -0500, Barry Warsaw wrote:
>     def _get_last_sent(self):
>         value = self._SO_get_last_sent()
>         return string_to_date(s)
> 
> This doesn't feel right because I have to do this transformation for
> every DateTimeCol attribute.

   Subclass DateTimeCol and assign a validator for it. Look at
UnicodeStringValidator and IntValidator for some examples.
   Make your validator as generic as possible, and publish the code for
discussion. Let us decide if it needs to be added to the SQLObject.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] datetime column conversions

[Oleg B. <ph...@ma...>]

On Wed, Jan 05, 2005 at 01:01:01PM -0500, Barry Warsaw wrote:
> I'm having one immediate problem though.  I have a DateTimeCol in one of
> my tables, and I set that column to an instance of a datetime.datetime
> object.  That's all fine and good because SQLObject turns that into a
> string and stores it properly in the SQLite database.  However, when I
> retrieve the column's value, I get a string back, not a datetime.

   You are just in time! Please look the archive for this mailing list
and reread messages for the last few days - the discussion about
string-to-int conversion in the IntCol. Just today I commited a number
of patches.

   Your problem is unfortunately a bit harder - what should toPython()
returns - a string? a datetime instance? a mx.DateTime instance?
Currently the column returns whatever the underlying driver returns.
What database and driver do you use?

   Check out the code from Subversion's trunk and give it a try - there
were a lot of bugs fixed since the release of SQLObject 0.6.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] datetime column conversions

[Barry W. <ba...@py...>]

I've just started using SQLObject -- I'm looking at it for a number of
projects -- and I like it.  Good work guys!  I /really/ like not having
to hand write all that SQL :).  FTR, I'm using Python 2.4, SQLite 3.0.8,
pysqlite 0.5.1, and SQLObject 0.6, all on a Gentoo Linux box.

I'm having one immediate problem though.  I have a DateTimeCol in one of
my tables, and I set that column to an instance of a datetime.datetime
object.  That's all fine and good because SQLObject turns that into a
string and stores it properly in the SQLite database.  However, when I
retrieve the column's value, I get a string back, not a datetime.

I know that SQLite doesn't have a DATETIME type, but still, I would
expect that if I store a value into a DateTimeCol, I would get a
datetime back.

My work around is simple, but it doesn't feel right:

def string_to_date(s):
    stime =3D time.strptime(s, '%Y-%m-%d %H:%M:%S')
    secs =3D time.mktime(stime)
    return datetime.datetime.fromtimestamp(secs)

class Thingie(sqlobject.SQLObject):
    # ...
    last_sent =3D DateTimeCol()
    def _get_last_sent(self):
        value =3D self._SO_get_last_sent()
        return string_to_date(s)

This doesn't feel right because I have to do this transformation for
every DateTimeCol attribute.  I've only taken a cursory look at the
code, but maybe it would be better to set a converter on the DateTimeCol
class, or to subclass, but I haven't gotten either of those approaches
to work.  Ideally, DateTimeCol would just hand me datetime instances. ;)

Suggestions, comments?

Thanks,
-Barry

Re: [SQLObject] Re: Strange column type conversion

[Oleg B. <ph...@ph...>]

On Wed, Jan 05, 2005 at 03:43:30PM +0300, Oleg Broytmann wrote:
> >    Also I am going to change SOUnicodeCol and apply the law of Demeter -
> > SOUnicodeCol should not instantiate UnicodeStringValidator by name -
> > that must be a parameter. This will allow to subclass SOUnicodeCol and
> > change that parameter.
> 
>    There are problems with test. I am working on them. One of the
> problems is that attemptConvert() in different validators have different
> number of parameters

   All fixes were commited at revision 516, and merged into the
inheritance branch at 517. All tests passed.

   Well, I am not sure I took a right path to fix validators.py by
renaming _(to/from)Python to (to/from)Python. I hope I haven't screwed
things up, neither techically nor ideologically. IWBN if people take a
look at the code and run tests.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Re: Strange column type conversion

[Oleg B. <ph...@ph...>]

On Mon, Jan 03, 2005 at 08:19:14PM +0300, Oleg Broytmann wrote:
> On Mon, Jan 03, 2005 at 10:57:10AM -0600, Ian Bicking wrote:
> > I agree that we should raise an exception when we get a non-integer. 
> > Well, int or long;
> 
>    Yes. I'll work on it.
>    Also I am going to change SOUnicodeCol and apply the law of Demeter -
> SOUnicodeCol should not instantiate UnicodeStringValidator by name -
> that must be a parameter. This will allow to subclass SOUnicodeCol and
> change that parameter.

   Committed at revision 511.

>    After that I'll implement IntValidator in the same model.

   Committed at revision 512.

   There are problems with test. I am working on them. One of the
problems is that attemptConvert() in different validators have different
number of parameters; that leads to the exception:

ERROR: testValidate (__main__.ValidationTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_sqlobject.py", line 894, in testValidate
    t = SOValidation(name='hey')
  File "/home/phd/work/SQLObject/SQLObject-inheritance_opt/sqlobject/main.py", line 1013, in __init__
    self._create(id, **kw)
  File "/home/phd/work/SQLObject/SQLObject-inheritance_opt/sqlobject/main.py", line 1065, in _create
    self.set(**kw)
  File "/home/phd/work/SQLObject/SQLObject-inheritance_opt/sqlobject/main.py", line 897, in set
    kw[name] = dbValue = fromPython(value, self._SO_validatorState)
  File "/home/phd/work/SQLObject/SQLObject-inheritance_opt/sqlobject/include/validators.py", line 202, in fromPython
    self.validateOther)
TypeError: attemptConvert() takes exactly 4 arguments (6 given)

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Strange column type conversion

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

Stuart Bishop wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Oleg Broytmann wrote:
> | On Mon, Jan 03, 2005 at 10:39:29PM +0800, Hong Yaun wrote:
> |
> |>But anyway, for a column decalred as IntCol, it
> |>should always return values as <type int>, and I wish this could be
> |>fixed soon, maybe by prohibiting to assign a string value to such a
> column.
> |
> |
> |    What do other people here think? Should the IntCol accept strings?
> | silently call int() on any input? or raise TypeError in case the input
> | value is not of type int?
> 
> It should accept anything that has an __sqlrepr__ shouldn't it?

Yeah, but that's an open bug too, e.g., the sqlbuilder.func.NOW() issue 
(where NOW() ends up being the column value, even though it's not a 
concrete Python value, just an abstract SQL expression).

Until that's fixed, it doesn't really help anyone to allow 
__sqlrepr__-having objects in.  Probably the fix would be to detect 
these objects, and if found call .expire() on the instance, forcing the 
data to be refetched on the next access.  Hmm... maybe that's not too hard.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

Re: [SQLObject] Strange column type conversion

[Stuart B. <st...@st...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oleg Broytmann wrote:
| On Mon, Jan 03, 2005 at 10:39:29PM +0800, Hong Yaun wrote:
|
|>But anyway, for a column decalred as IntCol, it
|>should always return values as <type int>, and I wish this could be
|>fixed soon, maybe by prohibiting to assign a string value to such a
column.
|
|
|    What do other people here think? Should the IntCol accept strings?
| silently call int() on any input? or raise TypeError in case the input
| value is not of type int?

It should accept anything that has an __sqlrepr__ shouldn't it?

class Default(object):
	def __sqlrepr__(self):
		return 'DEFAULT'

foo.someintcol = Default()

A similar use case would be set a value from a sequence, or for
calculations involving stored procedures.

Sticking an int() coersion in there would be nice, since I'd rather a
Python error early than waiting until the DB spits an error message at
me (important when working in lazy update mode). We have objects that
define an __int__() method that I think we pass to IntCols and expect it
to do the right thing.

- --
Stuart Bishop <st...@st...>
http://www.stuartbishop.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFB2pYMAfqZj7rGN0oRAvIRAJwJolGBLPKGQtVj6WwjHZhF0jnc/wCcDUgr
qQrX5gveQmjqyaLb9SmLvQA=
=1u6Z
-----END PGP SIGNATURE-----

Re: [SQLObject] Re: Strange column type conversion

[Oleg B. <ph...@ma...>]

On Mon, Jan 03, 2005 at 03:23:14PM -0200, Carlos Ribeiro wrote:
> On set: only int-like objects (longs included) should be accepted.

   Only int and long, and nothing else. Well, and subclasses -
if not isinstance(value, (int, long)): raise TypeError.

> On get: I still think that putting an int() there would not do any
> harm.

   Practicality beats purity. Let's wait for the real need of it.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Re: Strange column type conversion

[Carlos R. <car...@gm...>]

On Mon, 3 Jan 2005 20:19:14 +0300, Oleg Broytmann <ph...@ma...> wrote:
> On Mon, Jan 03, 2005 at 10:57:10AM -0600, Ian Bicking wrote:
> > I agree that we should raise an exception when we get a non-integer.
> > Well, int or long;
> 
>    Yes. I'll work on it.
>    Also I am going to change SOUnicodeCol and apply the law of Demeter -
> SOUnicodeCol should not instantiate UnicodeStringValidator by name -
> that must be a parameter. This will allow to subclass SOUnicodeCol and
> change that parameter.
>    After that I'll implement IntValidator in the same model.
> 
> > should a whole-number float also be accepted?
> 
>    No, in my humble opinion.

On set: only int-like objects (longs included) should be accepted.

On get: I still think that putting an int() there would not do any
harm. But I don't have strong opinions about it either.


-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

Re: [SQLObject] Re: Strange column type conversion

[Oleg B. <ph...@ma...>]

On Mon, Jan 03, 2005 at 10:57:10AM -0600, Ian Bicking wrote:
> I agree that we should raise an exception when we get a non-integer. 
> Well, int or long;

   Yes. I'll work on it.
   Also I am going to change SOUnicodeCol and apply the law of Demeter -
SOUnicodeCol should not instantiate UnicodeStringValidator by name -
that must be a parameter. This will allow to subclass SOUnicodeCol and
change that parameter.
   After that I'll implement IntValidator in the same model.

> should a whole-number float also be accepted?

   No, in my humble opinion.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Re: Strange column type conversion

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

Oleg Broytmann wrote:
>>silently convert the data back to int if, for some reason, a string is
>>read.
> 
>    Do you know a database or driver that return a string from an int
> column?!

The next version of PySQLite *might* return a string; the author 
mentioned that he wanted to get rid of the automatic conversion that the 
driver does.  Personally I think that's a bad choice, because it makes 
SQLite the odd one out of databases.

I agree that we should raise an exception when we get a non-integer. 
Well, int or long; should a whole-number float also be accepted?  I'm 
leaning towards not.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

Re: [SQLObject] Re: Strange column type conversion

[Carlos R. <car...@gm...>]

On Mon, 3 Jan 2005 19:15:33 +0300, Oleg Broytmann <ph...@ma...> wrote:
> On Mon, Jan 03, 2005 at 02:09:53PM -0200, Carlos Ribeiro wrote:
> > raise an exception for putting string data on an IntCol, but
> 
>    Yes, I think so, too.
> 
> > silently convert the data back to int if, for some reason, a string is
> > read.
> 
>    Do you know a database or driver that return a string from an int
> column?!

sqlite is very flexible in this regard; although it usually
differentiates between text & numeric columns, there's no coercion
AFAIK.

But let's generalize it; and before you tell me, I admit that it's
more a philosophical question than a practical one. Assume that I am
using SQLObject with an external database, in such a way that I can't
do anything about its schema. I want to treat the contents of a column
as an int. The original database may have been declared as anything -
an int, float, string, byte, shortint, whatever. But I know that the
value that's stored there can be read as a valid integer number. So I
declare it inside my app as an IntCol. If for any reason the value
can't be converted, it will raise an exception on read, just that.

In other words, I'm talking about being explicit... to the extreme.
The programmer asked for an IntCol. So the code always try to make
sure that it gets an int. If the programmer passes invalid data
(non-int), it raises an exception. But it also makes sure that the DB
is passing the correct data, so the match between the SQLObject and
the DB is also explicitly enforced on *read*.

Just my $0.02... and not that I'd bother very much about it, it was
just something that crossed my mind while reading the original thread.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

[SQLObject] Re: Re: Strange column type conversion

[Jorge L. G. F. <go...@ie...>]

Oleg Broytmann, Segunda 03 Janeiro 2005 14:15, wrote:

>    Do you know a database or driver that return a string from an int
> column?!

I think, I'm not sure here, that pyPgSQL does return strings only.

-- 
Godoy.     <go...@ie...>

Re: [SQLObject] Re: Strange column type conversion

[Oleg B. <ph...@ma...>]

On Mon, Jan 03, 2005 at 02:09:53PM -0200, Carlos Ribeiro wrote:
> raise an exception for putting string data on an IntCol, but

   Yes, I think so, too.

> silently convert the data back to int if, for some reason, a string is
> read.

   Do you know a database or driver that return a string from an int
column?!

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Re: Strange column type conversion

[Carlos R. <car...@gm...>]

On Mon, 03 Jan 2005 13:04:24 -0200, Jorge Luiz Godoy Filho
<go...@ie...> wrote:
> Oleg Broytmann, Segunda 03 Janeiro 2005 12:51, wrote:
> 
> >    What do other people here think? Should the IntCol accept strings?
> > silently call int() on any input? or raise TypeError in case the input
> > value is not of type int?
> 
> I go with Python's rule: explicit is better than implicit.

There's still Postel's law approach to consider: "be conservative in
what you do, be liberal in what you accept from others". In this case
it means raise an exception for putting string data on an IntCol, but
silently convert the data back to int if, for some reason, a string is
read.

Before anyone cries foul, it does make *at least some sense*. The user
determined that he wanted int's on his application, but he may not
have full control over the database. But to support this on SQLObject
or not, that's another issue entirely.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

[SQLObject] Re: Re: Strange column type conversion

[Jorge L. G. F. <go...@ie...>]

Jorge Luiz Godoy Filho, Segunda 03 Janeiro 2005 13:34, wrote:

> The use of a validator implies in code that I've written myself or opted
> in using.

I was thinking about a wxPython validator -- it was mentioned the use of
wxPython on the thread -- not on SQLObject's validators as you mentioned
while talking about UnicodeCol... 

-- 
Godoy.     <go...@ie...>

[SQLObject] Re: Re: Strange column type conversion

[Jorge L. G. F. <go...@ie...>]

Oleg Broytmann, Segunda 03 Janeiro 2005 13:15, wrote:

>    That is, do you prefer to convert by yourself? row.col = int(value)?
> Not even using a validator?

The use of a validator implies in code that I've written myself or opted in
using. 

Subclassing and making the subclass able to do an automatic conversion is
also interesting.



-- 
Godoy.     <go...@ie...>

Re: [SQLObject] Re: Strange column type conversion

[Oleg B. <ph...@ma...>]

On Mon, Jan 03, 2005 at 01:04:24PM -0200, Jorge Luiz Godoy Filho wrote:
> Oleg Broytmann, Segunda 03 Janeiro 2005 12:51, wrote:
> >    What do other people here think? Should the IntCol accept strings?
> > silently call int() on any input? or raise TypeError in case the input
> > value is not of type int?
> 
> I go with Python's rule: explicit is better than implicit.

   That is, do you prefer to convert by yourself? row.col = int(value)?
Not even using a validator?

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] Re: Strange column type conversion

[Jorge L. G. F. <go...@ie...>]

Oleg Broytmann, Segunda 03 Janeiro 2005 12:51, wrote:

>    What do other people here think? Should the IntCol accept strings?
> silently call int() on any input? or raise TypeError in case the input
> value is not of type int?

I go with Python's rule: explicit is better than implicit.

-- 
Godoy.     <go...@ie...>

Re: [SQLObject] Strange column type conversion

[Oleg B. <ph...@ma...>]

On Mon, Jan 03, 2005 at 10:39:29PM +0800, Hong Yaun wrote:
> But anyway, for a column decalred as IntCol, it 
> should always return values as <type int>, and I wish this could be 
> fixed soon, maybe by prohibiting to assign a string value to such a column.

   What do other people here think? Should the IntCol accept strings?
silently call int() on any input? or raise TypeError in case the input
value is not of type int?

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Strange column type conversion

[Hong Y. <hon...@ho...>]

Hello!

>>on the following grounds:
>>
>>I have encountered this problem when I am passing the user input value 
>>collected in the GUI components (wxPython in particular) to the 
>>database. The GUI components returns their values as string, so I would 
>>either convert the strings to integer in my own program, or have 
>>    
>>
>
>   The logic is flawed. You are connecting GUI and SQLObject in your
>program. The job of connecting and converting is neither in the GUI nor
>in SQLObject - it is the job of your program.
>   It is easy to implement, btw. See below.
>  
>
......

>>Second, I think this behavior is more compatible with the way that 
>>database is coping with type conversion. You can for example simply send 
>>a string in the SQL command to an int column in the database, and the 
>>database would perform the conversion whenever possible.
>>    
>>
>
>   I have never understand that behaviour of databases. And of
>programming langauges. Why on Earth one would want a typesystem where
>(s)he can add an integer to a string and got a result instead of
>TypeError?
>
>Oleg.
>  
>
I get your point, that the validating and type conversion belongs to the 
application itself, not the ORM or GUI layer. But at least I would be 
very happy if I could be spared the tedious job of doing simple and 
frequent conversions, specially the very common conversion from strings 
to numbers. As long as the program integrity is not engendered, the 
convenience of automatical conversion would always be welcome. For the 
end user at least, when she/he input a number in a field, she doesn't 
care whether it is actually a string or a number. For her it IS an 
nubmer. I think that is why the SQL standard is not so strict on the 
data types and most databases do a lot of automatic conversions.

I think it is rather a matter of taste whether a type system should be 
more strict or user friendly, and either way should work. It is just 
necessary to point out which approach SQLObject has taken so we know 
what is to be expected. But anyway, for a column decalred as IntCol, it 
should always return values as <type int>, and I wish this could be 
fixed soon, maybe by prohibiting to assign a string value to such a column.

Hong Yuan