Thread: PYTHON, ODBC

PYTHON, ODBC

From
mstory@uchicago.edu
Date:

We're looking into building a front end for our database in python.
The database in question is an educational database, that generates
new tables for each teacher, class and student.  Was wondering if
anyone had any recommendations for similar projects to look at,
resources, and general information about coding a python front end,
how to use the ODBC python libraries etc.

Thanks, matt

Re: PYTHON, ODBC

From
Pierre-Frédéric Caillaud
Date:
    Never used ODBC with Python, but if you want to use Postgres, I'd
strongly recommend psycopg which I find the nicest and fastest postgres
adapter (certainly a lot better than Pygresql and pypgsql)

    Regards

On Sat,  8 Jan 2005 18:01:01 -0600, <mstory@uchicago.edu> wrote:

>
>
> We're looking into building a front end for our database in python.
> The database in question is an educational database, that generates
> new tables for each teacher, class and student.  Was wondering if
> anyone had any recommendations for similar projects to look at,
> resources, and general information about coding a python front end,
> how to use the ODBC python libraries etc.
>
> Thanks, matt
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>



Re: PYTHON, ODBC

From
mstory@uchicago.edu
Date:
I've looked into pshycho pg, it appears to be the best option, my later question
now remains, what documentation or examples would be useful in developing a
completely proprietary front end written in python.  Any help finding useful
examples or documentation would be greatly appreciated.

thanks,
matt

Quoting Pierre-Frédéric Caillaud <lists@boutiquenumerique.com>:

>
>     Never used ODBC with Python, but if you want to use Postgres, I'd
> strongly recommend psycopg which I find the nicest and fastest postgres
> adapter (certainly a lot better than Pygresql and pypgsql)
>
>     Regards
>
> On Sat,  8 Jan 2005 18:01:01 -0600, <mstory@uchicago.edu> wrote:
>
> >
> >
> > We're looking into building a front end for our database in python.
> > The database in question is an educational database, that generates
> > new tables for each teacher, class and student.  Was wondering if
> > anyone had any recommendations for similar projects to look at,
> > resources, and general information about coding a python front end,
> > how to use the ODBC python libraries etc.
> >
> > Thanks, matt
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: you can get off all lists at once with the unregister command
> >     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> >
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
>                http://archives.postgresql.org
>



Re: PYTHON, ODBC

From
Pierre-Frédéric Caillaud
Date:
> completely proprietary front end written in python.  Any help finding
> useful

    What does "a completely proprietary front-end in python" means ?

Re: PYTHON, ODBC

From
Pierre-Frédéric Caillaud
Date:

> due to the complicated nature of the database, and inability of zope

    Well, I've found that Zope is very good to do a few things, and very bad
at the rest.

> to do what we need, and the problems with overhead we've been
> experiencing with rails due to the size of the database.  Hope this

    I like psycopy because selects with a lot of rows are processed
efficiently.

    Look at the pydo library in the skunkweb project (google !)

    I'd advise you to start writing a base class for your database object
(class DbObject) with a set of methods for setting instance methods from
query results. SELECT * then use cursor.dictfetchall() which preserves the
fields names !
    Add methods for inserting and updating.
    Add a mapping of fields to type converters (which are functions) to
convert non-standard types like arrays to python lists if you need them.

    Then derive your DbObject class for each table, with class variables
containing the field names and types converters, which will be used by the
base class. This way you can have a derived class with almost no code.

    Enjoy !

Re: PYTHON, ODBC

From
Matthew Story
Date:
we won't be using any tools aside from psycho pg, no gui application
frameworks, ie we're not using zope, ruby on rails, etc.  The front
end will only work for this particular database.  This has come about
due to the complicated nature of the database, and inability of zope
to do what we need, and the problems with overhead we've been
experiencing with rails due to the size of the database.  Hope this
clears things up a bit.

thanks,
matt


On Sun, 09 Jan 2005 14:56:57 +0100, Pierre-Frédéric Caillaud
<lists@boutiquenumerique.com> wrote:
> > completely proprietary front end written in python.  Any help finding
> > useful
>
>         What does "a completely proprietary front-end in python" means ?
>

Re: PYTHON, ODBC

From
Matthew Story
Date:
thanks for the advice,

matt


On Sun, 09 Jan 2005 20:47:08 +0100, Pierre-Frédéric Caillaud
<lists@boutiquenumerique.com> wrote:
>
>
> > due to the complicated nature of the database, and inability of zope
>
>         Well, I've found that Zope is very good to do a few things, and very bad
> at the rest.
>
> > to do what we need, and the problems with overhead we've been
> > experiencing with rails due to the size of the database.  Hope this
>
>         I like psycopy because selects with a lot of rows are processed
> efficiently.
>
>         Look at the pydo library in the skunkweb project (google !)
>
>         I'd advise you to start writing a base class for your database object
> (class DbObject) with a set of methods for setting instance methods from
> query results. SELECT * then use cursor.dictfetchall() which preserves the
> fields names !
>         Add methods for inserting and updating.
>         Add a mapping of fields to type converters (which are functions) to
> convert non-standard types like arrays to python lists if you need them.
>
>         Then derive your DbObject class for each table, with class variables
> containing the field names and types converters, which will be used by the
> base class. This way you can have a derived class with almost no code.
>
>         Enjoy !
>