[sqlalchemy] Row attributes from a table with renamed columns
Dear SQLAlchemists,
I'm trying to fetch some specific row attributes from a select statement on a
table. So far so good, this shouldn't be a problem... except this table
declares some renamed columns, using key, as:
sa.Column('the_label', sa.String(30), key='label')
When I'm inserting rows, the insert statement uses the renamed column
(label):
one_table.insert().execute(id=0,label='oula')
But when I'm selecting results and fetch some attributes on a given row, only
the original column names remain:
one_row = one_table.select().execute().fetchall()[0]
print attr = %s % one_row .label # error !
print orig attr = %s % one_row the_label # ok it works...
Is there any way to get the renamed columns on a RowProxy object ?
As attachment, a test case:
$ python table_with_key.py
Keys in row: ['id', 'the_label']
r.the_label: blabla
Traceback (most recent call last):
File table_with_key.py, line 25, in ?
print r.label: %s % r.label # won' work
File build/bdist.linux-i686/egg/sqlalchemy/engine/base.py, line 730, in
__getattr__
AttributeError: label
Thanks Cheers
Seb
--
Sébastien LELONG
sebastien.lelong[at]sirloon.net
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
table_with_key.py
Description: application/python
[sqlalchemy] postgres and server_side_cursors
Hi,
I'm trying the new server_side_cursors option with pg and I see that
I receive an error when I use the server_side_cursors=True and the Table
autoload=True. The autoload=True with the server_side_cursors=False
work. The server_side_cursors=True specifying the table structure work.
(I'm using the last svn version)
md_pg = BoundMetaData('postgres://[EMAIL PROTECTED]:5432/book',
server_side_cursors=False)
book_pg = Table('book', md_pg, autoload=True)
book_pg = Table('book', md_pg, autoload=True)
File /usr/lib/python2.4/site-packages/sqlalchemy/schema.py, line
143, in __call__
metadata.get_engine().reflecttable(table)
File /usr/lib/python2.4/site-packages/sqlalchemy/engine/base.py,
line 508, in reflecttable
self.dialect.reflecttable(conn, table)
File
/usr/lib/python2.4/site-packages/sqlalchemy/databases/postgres.py,
line 357, in reflecttable
for name, format_type, default, notnull, attnum, table_oid in rows:
File /usr/lib/python2.4/site-packages/sqlalchemy/engine/base.py,
line 732, in __iter__
yield self.__parent._get_col(self.__row, i)
File /usr/lib/python2.4/site-packages/sqlalchemy/engine/base.py,
line 634, in _get_col
rec = self._convert_key(key)
File /usr/lib/python2.4/site-packages/sqlalchemy/engine/base.py,
line 622, in _convert_key
rec = self.props[key]
KeyError: 0
smime.p7s
Description: S/MIME Cryptographic Signature
[sqlalchemy] Re: Row attributes from a table with renamed columns
try it in rev 2237 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: how to make a query for multilevel reference?
svilen wrote: But then query.select_by( name='whatever') may find different .name 's in the obj.hierarchy depending on dict.hashes/iteration, within same run or between different runs, returning very different queries... then just use select() for more specificity. Which means - cripple the _locate_prop() to look only 1 level down, making it predictable. it will match the first level it finds. its predictable. or.. let the wishful ones to hang themselves using literal strings into **kwargs ... (-:) Matching for key-subpaths within a key-tree (that is, object-attr-hierarchy) is a very powerful thing.. no need for wishing... just make yourself a MapperExtension that plugs whatever functionality you want into the select_by() method. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: ORM ramblings 2 - and announcing some o2r wrapper
while on polymorphic-union mappers vs non-polymorphic.. i have 3 kinds of type-queries: query_ALL-instances, quiery_BASE-instances, quiery_SUB-instances. First gives me all instances of a class or subclasess thereof, and is matching the main polymorphic-union mapper. The 3rd is a .select( table.c.typecolumn != base-type), piped through that too. For the 2nd one - getting the direct instances only (no subclasses) - i have a choice: a) have another non-primary mapper with some select( table.c.typecolumn==class_discriminator) as a table b) pipe this same select through the the main mapper So far i'm going the first way, but i'm not sure which one is better. Can u give any suggestion? If there are no big penalties for b), i will prefer that one; building another mapper was a tricky thing - and it does not work right now, for rev 2233. e.g. For a very simple case, B inh A, A points to self: ArgumentError: Cant determine relation direction for 'linkA' on mapper 'Mapper|A|bz4A|non-primary' with primary join 'bz4A. linkA_id = A.db_id' - foreign key columns are present in both the parent and the child's mapped tables. Specify 'foreign key' argument. Although the foreignkey _is_ there. i rmember this same error hapened before on some other occasion and then it disappeared. Anyway, if b) will work, i'll abandon it and not debug it to find why it breaks - unless you want it found and fixed. ciao svil --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: ORM ramblings 2 - and announcing some o2r wrapper
your best bet:
import pkg_resources as p
p.get_distribution('sqlalchemy').version
'0.3.3dev-r2190'
still researching ways to make that more integrated but setuptools
doesnt give a whole lot of options it seems.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: postgres and server_side_cursors
Michael Bayer wrote:
ive heard of this one already, which is why the option is turned off.
unfortunately I cant reproduce that here, so until someone wants to
figure out whats going on with that, not sure what I can do.
Tell me what I have to do. Here I have debian etch and pg 8.1.(the last
deb package)
I don't know if it can help, but a:
print key, self.props
at line 622 (so before the error), show me: 0 {}
we do have a ticket where someone commented that the server side
cursor will cause things like rowcount to not function until the
first row is fetched. I also do not observe that behavior on my
system...asked the guy to post what cases cause that, big surprise,
no response. its like our trac system is an oracle of shadowy myths
and rumors.
Just tried with a named cursor (conn.cursor(test)) with a raw
connection (without sa) and I see that the cur.rowcount have the number
of fetched records, so:
cur.execute(SELECT id FROM a_table_with_100k_rec)
cur.fetchone()
print cur.rowcount # print 1
cur.execute(SELECT id FROM a_table_with_100k_rec)
cur.fetchmany(1000)
print cur.rowcount # print 1000
Bye,
Michele
smime.p7s
Description: S/MIME Cryptographic Signature
[sqlalchemy] Re: how to make a query for multilevel reference?
Which means - cripple the _locate_prop() to look only 1 level down, making it predictable. it will match the first level it finds. its predictable. you have multiple levels of dictionaries. Traversing them is not really predictable (although stable if noone changes them, within same run). So if there is: class Address: street =Text() class Person: address_real = Address() address_official = Address() mother = Person() traversing through some person's attributes may in one run first find .street in person.address_real, in another run (or later in same run) in person.address_official. thus it's not really predictable. okay, i'm not arguing, maybe just put some warning about it in the doco or something. Making some dictionaries ordered maybe also a way, if dynamic adding of attributes/relations is not allowed. ciao svil --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: ORM ramblings 2 - and announcing some o2r wrapper
your best bet:
import pkg_resources as p
p.get_distribution('sqlalchemy').version
'0.3.3dev-r2190'
hm, this pkg_resources is from easy_setup or what? i dont have it.
still researching ways to make that more integrated but setuptools
doesnt give a whole lot of options it seems.
yeah, i used to generate my setup.py _only_ to have the version
automaticaly put somehow.
Maybe just add one simple .revision as of svn's $Revision$, that
should be okay for flying on devel.
but u'll need to setup a svn autoprop for that, add . ~/.subversion
[miscellany]
enable-auto-props = yes
[auto-props]
*.py = svn:keywords=Id Revision
well, not something pretty either...
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: postgres and server_side_cursors
Michael Bayer wrote:
ive heard of this one already, which is why the option is turned off.
unfortunately I cant reproduce that here, so until someone wants to
figure out whats going on with that, not sure what I can do.
After some tries, I see that is I wrote (very bad code line):
cursor.cursor.fetchone()
at line 553 at engine/base.py, all work.
with a:
print cur descr bef, cursor.description
cursor.cursor.fetchone()
print after, cursor.descriptio
cur descr bef
None after (('col1', 25, 10, -1, None, None, None), ...
end so on
Michele
smime.p7s
Description: S/MIME Cryptographic Signature
[sqlalchemy] Re: ORM ramblings 2 - and announcing some o2r wrapper
limited to non_primary mapper ? creating relationships with non_primary mapper is a bad idea. the foreignkey error really means, cant find a foreignkey *that I recognize as part of the parent or child tables*. On Jan 23, 2007, at 12:43 PM, svilen wrote: while on polymorphic-union mappers vs non-polymorphic.. i have 3 kinds of type-queries: query_ALL-instances, quiery_BASE-instances, quiery_SUB-instances. First gives me all instances of a class or subclasess thereof, and is matching the main polymorphic-union mapper. The 3rd is a .select( table.c.typecolumn != base-type), piped through that too. For the 2nd one - getting the direct instances only (no subclasses) - i have a choice: a) have another non-primary mapper with some select( table.c.typecolumn==class_discriminator) as a table b) pipe this same select through the the main mapper So far i'm going the first way, but i'm not sure which one is better. Can u give any suggestion? If there are no big penalties for b), i will prefer that one; building another mapper was a tricky thing - and it does not work right now, for rev 2233. e.g. For a very simple case, B inh A, A points to self: ArgumentError: Cant determine relation direction for 'linkA' on mapper 'Mapper|A|bz4A|non-primary' with primary join 'bz4A. linkA_id = A.db_id' - foreign key columns are present in both the parent and the child's mapped tables. Specify 'foreign key' argument. Although the foreignkey _is_ there. i rmember this same error hapened before on some other occasion and then it disappeared. Anyway, if b) will work, i'll abandon it and not debug it to find why it breaks - unless you want it found and fixed. ciao svil --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: how to make a query for multilevel reference?
yes, if you have two relations at the *same* level, both of which will lead to the same named property within, then select_by() by itself is useless. if you are querying for a relaton that you think is local, and its not and then it magically traverses down and finds the wrong property, then its wrong regardless of whether multiple matching relationships exist or not...you expected it to only remain within the first level. the error in that behavior will become apparent very quickly. if you are relying upon the deep traversal behavior, then you'd better know what youre doing. so far, nobody's ever had a problem with it. my litmus test to remove an API and replace with something else usually starts with users keep getting errors with the current API, so this is not hitting that point yet. the best way by far is to just use SelectResults and be explicit. I should add a select_by() to SelectResults though. im not thrilled with the inconvenience of using SelectResults and wish I had written Query to be more like it in the first place; but it is a different approach than Query and I would rather not conflate the two approaches. On Jan 23, 2007, at 12:53 PM, svilen wrote: Which means - cripple the _locate_prop() to look only 1 level down, making it predictable. it will match the first level it finds. its predictable. you have multiple levels of dictionaries. Traversing them is not really predictable (although stable if noone changes them, within same run). So if there is: class Address: street =Text() class Person: address_real = Address() address_official = Address() mother = Person() traversing through some person's attributes may in one run first find .street in person.address_real, in another run (or later in same run) in person.address_official. thus it's not really predictable. okay, i'm not arguing, maybe just put some warning about it in the doco or something. Making some dictionaries ordered maybe also a way, if dynamic adding of attributes/relations is not allowed. ciao svil --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] SA 0.3.4 released
hey list - I cant keep up with all thats going on at this point, and the trunk was just burstingso I need to get out what we have thus far and see how far it flies. This release has some fairly deep refactorings involving mapper relationships, particularly those involving polymorphic mappers, as well as changes right up to the last minute (which is typical), so any new issues just chime in. big bugs that were fixed include: - fixed bug in mapper refresh/expire whereby eager loaders didnt properly re-populate item lists [ticket:407] - fixed bug where delete-orphan basically didn't work with many-to- many relationships [ticket:427], backref presence generally hid the symptom and possibly: - added a mutex to the mapper compilation step. that is, if you were running SA in a super-concurrent environment and getting errors/crashes when a process first started. 0.3.4 - general: - global insure-ensure change. in US english insure is actually largely interchangeable with ensure (so says the dictionary), so I'm not completely illiterate, but its definitely sub-optimal to ensure which is non-ambiguous. - sql: - added fetchmany() support to ResultProxy - added support for column key attribute to be useable in row [key]/row.key - changed BooleanExpression to subclass from BinaryExpression, so that boolean expressions can also follow column-clause behaviors (i.e. label(), etc). - trailing underscores are trimmed from func.xxx calls, such as func.if_() - fix to correlation of subqueries when the column list of the select statement is constructed with individual calls to append_column(); this fixes an ORM bug whereby nested select statements were not getting correlated with the main select generated by the Query object. - another fix to subquery correlation so that a subquery which has only one FROM element will *not* correlate that single element, since at least one FROM element is required in a query. - default timezone setting is now False. this corresponds to Python's datetime behavior as well as Postgres' timestamp/time types (which is the only timezone-sensitive dialect at the moment) [ticket:414] - the op() function is now treated as an operation, rather than a comparison. the difference is, an operation produces a BinaryExpression from which further operations can occur whereas comparison produces the more restrictive BooleanExpression - trying to redefine a reflected primary key column as non-primary key raises an error - type system slightly modified to support TypeDecorators that can be overridden by the dialect (ok, thats not very clear, it allows the mssql tweak below to be possible) - mssql: - added an NVarchar type (produces NVARCHAR), also MSUnicode which provides Unicode-translation for the NVarchar regardless of dialect convert_unicode setting. - postgres: - fix to the initial checkfirst for tables to take current schema into account [ticket:424] - postgres has an optional server_side_cursors=True flag which will utilize server side cursors. these are appropriate for fetching only partial results and are necessary for working with very large unbounded result sets. While we'd like this to be the default behavior, different environments seem to have different results and the causes have not been isolated so we are leaving the feature off by default for now. Uses an apparently undocumented psycopg2 behavior recently discovered on the psycopg mailing list. - added BIGSERIAL support for postgres table with PGBigInteger/ autoincrement - fixes to postgres reflection to better handle when schema names are present; thanks to jason (at) ncsmags.com [ticket:402] - mysql: - mysql is inconsistent with what kinds of quotes it uses in foreign keys during a SHOW CREATE TABLE, reflection updated to accomodate for all three styles [ticket:420] - mysql table create options work on a generic passthru now, i.e. Table(..., mysql_engine='InnoDB', mysql_collate=latin1_german2_ci, mysql_auto_increment=5, mysql_somearg...), helps [ticket:418] - firebird: - order of constraint creation puts primary key first before all other constraints; required for firebird, not a bad idea for others [ticket:408] - Firebird fix to autoload multifield foreign keys [ticket:409] - Firebird NUMERIC type properly handles a type without precision [ticket:409] - oracle: - *slight* support for binary, but still need to figure out how to insert reasonably large values (over 4K). requires auto_setinputsizes=True sent to create_engine(), rows must be fully fetched individually, etc. - orm: - poked the first hole in the can of worms: saying query.select_by (somerelationname=someinstance) will create the join of the primary key columns represented by
[sqlalchemy] Re: ORM ramblings 2 - and announcing some o2r wrapper
limited to non_primary mapper ? creating relationships with non_primary mapper is a bad idea. the foreignkey error really means, cant find a foreignkey *that I recognize as part of the parent or child tables*. hmmm. u mean, making the non-primary mapper equivalent (relation-wise) to the main mapper is no good? i don't use it for saving any data, only for fetching. okay, i'll try piping the select through main-mapper... On Jan 23, 2007, at 12:43 PM, svilen wrote: while on polymorphic-union mappers vs non-polymorphic.. i have 3 kinds of type-queries: query_ALL-instances, quiery_BASE-instances, quiery_SUB-instances. First gives me all instances of a class or subclasess thereof, and is matching the main polymorphic-union mapper. The 3rd is a .select( table.c.typecolumn != base-type), piped through that too. For the 2nd one - getting the direct instances only (no subclasses) - i have a choice: a) have another non-primary mapper with some select( table.c.typecolumn==class_discriminator) as a table b) pipe this same select through the the main mapper So far i'm going the first way, but i'm not sure which one is better. Can u give any suggestion? If there are no big penalties for b), i will prefer that one; building another mapper was a tricky thing - and it does not work right now, for rev 2233. e.g. For a very simple case, B inh A, A points to self: ArgumentError: Cant determine relation direction for 'linkA' on mapper 'Mapper|A|bz4A|non-primary' with primary join 'bz4A. linkA_id = A.db_id' - foreign key columns are present in both the parent and the child's mapped tables. Specify 'foreign key' argument. Although the foreignkey _is_ there. i rmember this same error hapened before on some other occasion and then it disappeared. Anyway, if b) will work, i'll abandon it and not debug it to find why it breaks - unless you want it found and fixed. ciao svil --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: KeyError: 'inet'
Hi There Thanks for the patch. It seems to fix the error. I will test it more over the following days. I see that you just released a new SA, but I dont see this patch in the changelog. Did it go in? Thanks Peter On Tue 16 Jan 2007 21:44, Michael Bayer wrote: its quite easy to add this type in. im not exactly sure what python type it should accept/return so you can start with just this patch: Index: lib/sqlalchemy/databases/postgres.py === --- lib/sqlalchemy/databases/postgres.py(revision 2199) +++ lib/sqlalchemy/databases/postgres.py(working copy) @@ -32,6 +32,10 @@ except: psycopg = None +class Inet(sqltypes.TypeEngine): +def get_col_spec(self): +return INET + class PGNumeric(sqltypes.Numeric): def get_col_spec(self): if not self.precision: @@ -161,6 +165,7 @@ 'numeric' : PGNumeric, 'float' : PGFloat, 'real' : PGFloat, +'inet': Inet, 'double precision' : PGFloat, 'timestamp' : PG2DateTime, 'timestamp with time zone' : PG2DateTime, additionally you can skip the reflection step and/or override the Inet columns with any old type explicitly to avoid the failing dictionary lookup (if you dont feel like using the above patch). --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc pgplMXmPIMzpQ.pgp Description: PGP signature
[sqlalchemy] Re: KeyError: 'inet'
no, youre testing it for me first :) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: ORM ramblings 2 - and announcing some o2r wrapper
okay, let me release something too. http://linuxteam.sistechnology.com/o2rm/sawrap0124.tar.bz2 i'm still looking for a name... Basic idea of this SAwrapper is to be 3rd-level declarative translator (SA has 2, non-declarative: orm-sqlpy, sqlpy-sql-dialect) and hide the SA's specifics, i.e. OBJ-SAorm. What's in now: - all possible single relations of objects with =2 levels of inheritance are translated correctly (tests/sa_ref_A_B_A_all.py and tests/test_A_B_inh_ref_all.py) - some multilevel inheritances also can be mapped - see doc/example.py - YMMV - removed staticType stuff, will be released separate + it's adapter/wrapper - can generate a flat source-code for the prepared tables/mappers/etc (well, mostly) - for testcases etc. - needs sqlalchemy 0.3.4 what's to todo: - 3+ level inheritances, as well as mixed-type inheritances, do not work well (if at all) - fix current and do more tests - converting expressions into table.column-clauses - many2* relations basic usage: - declare your types as inheriting sawrap.plainwrap.Type (empty is ok) - declare your class hierarchy starting off sawrap.plainwrap.Base - declare attributes as instance/s of above Types - declare references as instances of sawrap.plainwrap.Type4SubStruct(name) - choose DB_inheritance decomposition type at each class - create fieldtypemap as a dictionary yourType:sqlalchemy.type - create SAdb() instance - sadb.bind( dict-of-all-classes, fieldtypemap, base_klas=yourbase) -- declarative phase ends here - all info is available, tables+mappers are built now. - populate - create obj-instances, fill them, link them. Then make session, and either use sadb.saveall( namespace-of-all-instances) or save them one by one. - query - use some of sadb.query_ALL_instances(), sadb.query_BASE_instances(), query_SUB_instances(), then do .select(..) over them - have a drink... or two. $ PYTHONPATH=sawrap/ python sawrap/doc/example.py ciao svil --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- example.py Description: application/python
[sqlalchemy] Re: SQLite, append_column?
So, there is no way to add new column to existing table? Or I can use ALTER TABLE and how to save existing data on table alter? Thanks! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: postgres and server_side_cursors
I think I was the original person who had this problem. I found a bit of time to troubleshoot it and came up with a patch. The problem seems to be in ResultProxy when it does the metadata = cursor.description bit. cursor.description is returning None because the cursor has not had any rows fetched yet. If I do a cursor.fetchone () then cursor.description returns the expected result. So it looks like the solution here is to defer the metadata translation (construction of ResultProxy.props) until after some data has been fetched from the cursor. Patch attached (works for me, but not heavily tested). ~ Daniel --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- server_side_cursors.patch Description: Binary data On Jan 23, 2007, at 11:22 AM, Michael Bayer wrote: ive heard of this one already, which is why the option is turned off. unfortunately I cant reproduce that here, so until someone wants to figure out whats going on with that, not sure what I can do. we do have a ticket where someone commented that the server side cursor will cause things like rowcount to not function until the first row is fetched. I also do not observe that behavior on my system...asked the guy to post what cases cause that, big surprise, no response. its like our trac system is an oracle of shadowy myths and rumors. so if anyone wants to wrestle with the psycopg2 guys on this, and/or figure out what the issue is, they seem to be generally not excited by server side cursors in the first place, in favor of just using LIMIT on your SQL so that there is little advantage to the server side approach. from my point of view its not a critical issue since its true, you can just use LIMIT as appropriate. --~--~-~--~~~---~--~~ 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 sqlalchemy- [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/ group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: postgres and server_side_cursors
ugh, adds an extra conditional into every fetchone() :) On Jan 23, 2007, at 10:06 PM, Daniel Miller wrote: I think I was the original person who had this problem. I found a bit of time to troubleshoot it and came up with a patch. The problem seems to be in ResultProxy when it does the metadata = cursor.description bit. cursor.description is returning None because the cursor has not had any rows fetched yet. If I do a cursor.fetchone () then cursor.description returns the expected result. So it looks like the solution here is to defer the metadata translation (construction of ResultProxy.props) until after some data has been fetched from the cursor. Patch attached (works for me, but not heavily tested). ~ Daniel server_side_cursors.patch On Jan 23, 2007, at 11:22 AM, Michael Bayer wrote: ive heard of this one already, which is why the option is turned off. unfortunately I cant reproduce that here, so until someone wants to figure out whats going on with that, not sure what I can do. we do have a ticket where someone commented that the server side cursor will cause things like rowcount to not function until the first row is fetched. I also do not observe that behavior on my system...asked the guy to post what cases cause that, big surprise, no response. its like our trac system is an oracle of shadowy myths and rumors. so if anyone wants to wrestle with the psycopg2 guys on this, and/or figure out what the issue is, they seem to be generally not excited by server side cursors in the first place, in favor of just using LIMIT on your SQL so that there is little advantage to the server side approach. from my point of view its not a critical issue since its true, you can just use LIMIT as appropriate. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: SQLite, append_column?
SA doesn't support doing ADD COLUMN or almost any other ALTER command. If you ran the ALTER manually then created a new Table with autoload it would of course load the new version, but I'm at a loss to see why you'd need that. On 1/23/07, Basil Shubin [EMAIL PROTECTED] wrote: So, there is no way to add new column to existing table? Or I can use ALTER TABLE and how to save existing data on table alter? Thanks! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
