Here's a patch that add's a DelayedMetaResultProxy(ResultProxy) class. In the case of fetchone and fetchmany, it overwrites itself with the ResultProxy's version after the first call. Actually, fetchone calls the super class's initially and simply sets the metadata before returning. I would have done that for all of the affected functions with a decorator, but the close() call in the others causes trouble.
On 3/17/07, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
> no its a psycopg thing, its like this:
>
> # server side cursor (giving it a name makes it "server side".
> psycopg2 devs think thats a good API.)
> cursor = connection.cursor("x")
>
> # execute. cursor now has pending results.
> cursor.execute("select * from table")
>
> SQLAlchemy's result wrapper, ResultProxy, then calls:
>
> metadata = cursor.metadata
>
> in order to get information about the columns in the result set. but
> *this fails*, because we are using server side cursors, and
> "metadata" apparently does not know to fetch its info from the
> server. doesnt happen on my machine. not sure if this changes due
> to psycopg2 versions, PG setup, or what. if we can determine its a
> psycopg2 version issue, then everyone can just upgrade.
>
> anyway what psycopg wants you to do is:
>
> row = cursor.fetchone()
> metadata = cursor.metadata
>
> then it works. a tweaked out ResultProxy is needed to handle this
> extra complexity in this case.
>
> if youre saying we shouldnt use "metadata" at all, that doesnt work
> because ResultProxy is globally used for all results regardless of
> their source, textual, column-based, and otherwise. also the
> databases will often not give you back the same column name as what
> you gave it (case conventions, etc) and in some cases we dont even
> have a column name to start with (like "select some_function()").
>
> On Mar 17, 2007, at 8:41 PM, Steve Huffman wrote:
>
> >
> > I may be missing something fundamental here, but why doesn't it
> > already know the metadata since I defined the columns in which I'm
> > interested?
> >
> > thing_table = sa.Table("thing", md, sa.Column('id', sa.Integer,
> > primary_key = True))
> >
> > On 3/17/07, Michael Bayer <[EMAIL PROTECTED]> wrote:
> >>
> >> the cursor metadata often cannot be read until fetchone() is called
> >> first. the current result set implementation we have doesnt call
> >> fetchone() before it tries to get the metadata, and normally it
> >> shouldnt (since the result set doesnt even know if its the result
> >> of a
> >> select/insert/whatever). id like an alternate result set class
> >> to go
> >> into effect when PG/server side cursors/select is used to do this, i
> >> think someone was supposed to send a patch. its hard for me to
> >> develop since my version of PG 8.1 doesnt seem to reproduce the
> >> issue.
> >>
> >> On Mar 17, 8:14 pm, "[EMAIL PROTECTED]"
> >> <[EMAIL PROTECTED]> wrote:
> >>> I was excited to see the server_side_cursors option that was added
> >>> recently.
> >>>
> >>> I saw the reports of it not working with autoload = True, but I've
> >>> been having trouble getting it to work at all.
> >>>
> >>> When attempting to select a row using:
> >>>
> >>>>>> t2.select().execute().fetchone()
> >>>
> >>> I get:
> >>>
> >>> INFO sqlalchemy.engine.base.Engine.0x..d0 SELECT thing.id FROM thing
> >>> INFO sqlalchemy.engine.base.Engine.0x..d0 {}
> >>> Traceback (most recent call last): File "<stdin>", line 1, in ?
> >>> File "build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py",
> >>> line
> >>> 811, in __repr__
> >>> File "build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py",
> >>> line
> >>> 671, in _get_col
> >>> File "build/bdist.linux-x86_64/egg/sqlalchemy/engine/base.py",
> >>> line
> >>> 659, in _convert_key
> >>> sqlalchemy.exceptions.NoSuchColumnError: "Could not locate column in
> >>> row for column '0'"
> >>>
> >>> This query runs fine without server_side_cursors = True
> >>>
> >>> Any suggestions?
> >>
> >>
> >>>
> >>
> >
> > >
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
postgres_delay_metadata.patch
Description: Binary data
