Re: Change in datetime type casting
От | Adrian Klaver |
---|---|
Тема | Re: Change in datetime type casting |
Дата | |
Msg-id | 4FEDC48C.6050309@gmail.com обсуждение исходный текст |
Ответ на | Re: Change in datetime type casting (Karsten Hilbert <Karsten.Hilbert@gmx.net>) |
Список | psycopg |
On 06/29/2012 07:59 AM, Karsten Hilbert wrote: > On Fri, Jun 29, 2012 at 07:51:44AM -0700, Adrian Klaver wrote: > >>>> Which begs the question why does the adapter not do str(value) when creating >>>> the ARRAY? >>> >>> Because it would give a false promise of working. If I put a date in >>> my db, I'm expecting a date to come out: any other result is an error. >>> The hstore adapter is documented to take strings mapping: results with >>> any other mapping is undefined. A better behaviour could be to >>> explicitly raise an explicit exception, but it would be less efficient >>> than trusting the user he is using the adapter as documented (see >>> HstoreAdapter._getquoted_9(): we adapt the dict.values() list, not >>> iterate on each values). >>> >>> If writing a date in and reading a string out is enough for your >>> application, you can easily write your own specialized hstore adapter >>> based on the code in extras.py. >> >> The following change in extras.py solves the problem for dates and >> other non string types.: >> >> class HstoreAdapter(object): >> """Adapt a Python dict to the hstore syntax.""" >> def __init__(self, wrapped): >> self.wrapped = wrapped >> for k in self.wrapped: <-- >> self.wrapped[k] = str(self.wrapped[k]) <-- >> >> Is there a possibility it could find its way into psycopg2 proper? > > It would not solve this concern voiced above: > >>> Because it would give a false promise of working. As I said before there is no false promise. hstore is just a fancy string type. There is no expectation that types will be preserved, so why maintain the illusion? > > Karsten > -- Adrian Klaver adrian.klaver@gmail.com
В списке psycopg по дате отправления: