Yes.
I'm saying I can't find my test case that was failing without it (although
I'm still trying to recreate one).
> I thought this was a performance issue as well as db(...).select()
returns parsed types and it is best if the driver does it as opposed if
web2py does it.
It probably is better when the driver does it -- both in the sense of being
faster (though need benchmark to prove it) and of being compatible with the
"standard" handling; e.g., if you use the PARSE_DECL and your database
already contains data that has microseconds, then you will get them when
selecting (because the database will produce datetime() objects), whereas if
you don't use PARSE_DECL and let web2py do the parsing, those will be
silently ignored.
The difference in behavior is given in this example:
------------------------
# testapp/models/test.py
db.define_table('test', Field('t', 'datetime'))
db.test.insert(t=request.now)
# without PARSE_DECLTYPES
./web2py.py -M -S testapp
In [1]: db.executesql('select * from test')
Out[1]: [(1, u'2011-09-14 09:49:00')]
# with PARSE_DECLTYPES
./web2py.py -M -S testapp
In [1]: db.executesql('select * from test')
Out[1]: [(1, datetime.datetime(2011, 9, 14, 9, 56, 36))]
-----------------------
I was sure I had an example where the strings were received from a select(),
but I can't find one in my repository and I can't recreate one. I still
think the PARSE_DECLTYPES addition is useful for all the reasons above, but
it is obviously not as critical as I thought -- I apologies for bringing
this up several times, I should have posted a test when I first posted about
it.
(Also - I just did hg pull, but did not see it in dal.py -- is development
happening on a place other then the hg tip?)
Apologies again.
