On Apr 17, 2007, at 4:12 PM, Federico Di Gregorio wrote:
>
> The Python->SQL part is perfect for adaptation and, for example,
> psycopg
> has a micro-protocols implementation to help with the adaptation of
> any
> Python object into a valid ISQLQuote one. Why two different systems?
> Because
Art Protin wrote:
> Our database system has an nearly unbounded set of types.
> The types have two components, say a major and minor,
> or a main type and subtype. The main type "STRING" alone
> has 65535 subtypes (one for each allowable size).
> Other main types may a few subtypes or even no subt
Il giorno mar, 17/04/2007 alle 13.53 -0400, Michael Bayer ha scritto:
> However i might suggest that this whole thread, "controlling return
> types", perhaps be expanded to include "controlling *input* types and
> return types", since to me (as well as to SQLAlchemy) being able to
> send an a
Il giorno mar, 17/04/2007 alle 10.35 -0700, Robert Brewer ha scritto:
[...]
> This is where Geniusql is headed. I'm not for a moment saying the DBAPI
> should go that far, but there needs to be a clear understanding of
> exactly how far the DBAPI is going to go down this rabbit hole (because
> howe
Michael Bayer wrote:
> However i might suggest that this whole thread, "controlling return
> types", perhaps be expanded to include "controlling *input* types and
> return types"
The pysqlite register_adapter and register_converter do this (in that
order). I've not used it in
On Apr 17, 2007, at 10:51 AM, Art Protin wrote:
> Yes, something nice and simple, like a dict using the string name
> of the DBMS native
> datatype as the index. However, this might not work out after
> all. Our database
> system has an nearly unbounded set of types. The types have two
>
Federico Di Gregorio wrote:
> Il giorno mar, 17/04/2007 alle 10.16 +0200, M.-A. Lemburg ha scritto:
> >
> > While this can be solved using a registry of types conversions,
> > I see problems in standardizing the way to define the type
> > mappings since different database backends tend to have
> >
Folks,
This conversation is excellent.
I have also experienced the need to extend our driver in non-standard
ways in support
of datatypes (as well as in other dimensions.) I added an attribute to
cursors .datetime_type
to indicate whether to leave them as strings (as converted by our DBMS
Il giorno mar, 17/04/2007 alle 10.16 +0200, M.-A. Lemburg ha scritto:
>
> While this can be solved using a registry of types conversions,
> I see problems in standardizing the way to define the type
> mappings since different database backends tend to have
> or need different types.
I can see an
On 2007-04-17 06:05, Jim Patterson wrote:
> All,
>
> Over on the cx_Oracle list we have been discussing adding support
> for returning native Unicode strings and decimal objects. We have
> so far been talking about using a settable attribute on the connection
> and the cursor with the cursor inhe
Il giorno mar, 17/04/2007 alle 00.05 -0400, Jim Patterson ha scritto:
> Over on the cx_Oracle list we have been discussing adding support
> for returning native Unicode strings and decimal objects. We have
> so far been talking about using a settable attribute on the connection
> and the cursor wi
11 matches
Mail list logo
