[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-db-sig
Subject:    [DB-SIG] Sybase module, DB-api description attribute
From:       pgodman () halcyon ! com (Peter Godman)
Date:       1998-04-14 18:02:39
Message-ID: Pine.GUL.3.96.980414104353.28501A-100000 () coho ! halcyon ! com
[Download RAW message or body]

On Tue, 14 Apr 1998, Harri Pasanen wrote:

> Hi,
> 
> What is the current status of Sybase module development?
> 

I sent an email a few days ago stating the current status of module
development for me... not much, pending access to a Sybase database.  I'm
working on getting access, though.

> I've been testing Peter Godman's ctsybase module on SunOS 5.6 with
> Python 1.5, and my
> preliminary tests seem to have it functioning ok.
> 
> But how is the description attribute supposed to be populated?   The
> current ctsybase module
> seems to fill it mainly with raw return values of Sybase, so the column
> description tuples look something
> like ('name', 0, 0, 255, 0, 0, 0)

Well, I tried to do what the spec said, with some amount of trepidation,
given the closing disclaimer.

description 
        This read-only attribute is a tuple of 7-tuples. /* I did a list 
	                                                    of 7-tuples */
        Each 7-tuple contains information describing each result column:
        (name, type_code, display_size, internal_size, precision, scale, 
	null_ok). This attribute will be None for operations that do 
	not return rows or if the cursor has not had an operation invoked 
	via the execute() method yet.  The type_code is one of the dbi 
	values specified in the section below. 

        Note: this is a bit in flux. Generally, the first
        two items of the 7-tuple will always be present; the others may be
                        database specific. 

However, there is no available display length, and the data type is
returned, as you suspected, as a sybase constant.  I should add these
constants to the module.  

I will be able to do something a little more elegant when I add dbi types.  

> 
> Has there been any talk about getting more detailed meta data out of
> databases, for instance where
> the DBI object types would be a union of all supported database types?
>

I think this is a good idea.  However, I think people are still going to
want to deal with native types where possible.  Furthermore, the range of
types supported by a database varies widely, making a union messy, and may
not even be known upon installation (user may install her own complex
types). 

> 
> Thanks,
> 
> Harri
> 

Thanks, 
Pete

> 
> ------------------------------------------------------
> DB-SIG maillist  -  DB-SIG@python.org
> http://www.python.org/mailman/listinfo/db-sig
> 



[prev in list] [next in list] [prev in thread] [next in thread]