[sqlalchemy] Re: use_labels =30 vs MAX_LABEL_LENGTH
Michael Bayer wrote: ideally the truncation should be occuring at the SQL compilation phase so you wouldnt have this problem. i recall that being very complex but i should take a look again to see if theres any major barriers to that. but for now, sure, ive no problem with a module-level global. just be aware that if i fix this in a better way it might be removed in a later release. actually, we have this restriction because Oracle and Firebird use short names. May be you may assign the MAXLENGTH depending on the database, for example: * MySQL = 64 * PostgreSQL = 64 - 1 * Firebird = 31 ? * Oracle = 30 * MS-SQL = 128 * SQLite = no limites (The name and CREATE TABLE statement for a table must fit entirely within a 1-megabyte row of the SQLITE_MASTER table. Other than this, there are no constraints on the length of the name of a table, or on the number of columns, etc. Indices are similarly unconstrained). On Mar 16, 2007, at 4:05 PM, Jose Soares wrote: Hi Michael, I see that sql.py uses a limit of 30 characters to create the column label when use_labels is set to True. If name is greater than 30 char long, the label is trunked at position 24 and is appended a random integer to it. Since the name created in this way is less useful, I would like to sugest you to customize the maxlength of column names. (PostgreSQL accepts until 63 characters for names, with SQLite you may use very, very long names) --~--~-~--~~~---~--~~ 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: use_labels =30 vs MAX_LABEL_LENGTH
jose [EMAIL PROTECTED] writes: * PostgreSQL = 64 - 1 This can be changed in compilation time. -- Jorge Godoy [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: use_labels =30 vs MAX_LABEL_LENGTH
On Mar 17, 3:57 am, jose [EMAIL PROTECTED] wrote: May be you may assign the MAXLENGTH depending on the database, for example: * MySQL = 64 * PostgreSQL = 64 - 1 * Firebird = 31 ? * Oracle = 30 * MS-SQL = 128 well yes thats the whole issue. we are doing the length truncation at the point at which you create a SQL construct. s = select([foo.label(im_a_long_label]) no dialect/database has entered the equation at that point. --~--~-~--~~~---~--~~ 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: Inconsistent results in session.flush()
On Mar 16, 9:50 pm, Michael Bayer [EMAIL PROTECTED] wrote: oh, this is easy. you have a circular insert relationship between label and release_line, which you can see in the sort there (the cycles:) as well as evidenced by the fact that you have a use_alter needed in order to create the foreign keys on those two tables. add post_update=True to one of the relationships which will break that particular cycle by using a second UPDATE statement, and youre in. Brilliant - that did it. Thanks a lot. Is there any way that SA could have raised an error in this situation? I think this would be very tricky for someone unfamiliar with the SA internals to debug, particularly as it doesn't occur every time. Are there situations where it is reasonable to have cycles without post_update? I had assumed that post_update was only necessary when you are inserting two rows that are mutually dependent, but in this case I wasn't inserting either a ReleaseLine or a Label. I suppose post_update can actually have a knock-on affect across the whole dependency graph. Anyway, thanks a lot again for your help, Simon --~--~-~--~~~---~--~~ 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] Bug?
Hi,
I'm having a problem where the result of 2 programs with the same code
is different.
Program A :
from sqlalchemy import *
db = create_engine('sqlite:///test18.db')
db.echo = False
metadata = BoundMetaData(db)
users = Table('users', metadata,
Column('user_id', Integer, primary_key=True),
Column('name', String(40)),
Column('age', Integer),
Column('password', String),
)
users.create()
users = Table('users', metadata, autoload=True)
class User(object):
pass
usermapper = mapper(User, users)
session = create_session()
user1 = User()
user1.name = 'TOTO'
user1.age = 19
session.save(user1)
session.flush
result = users.select().execute()
row = result.fetchall()
print row
== result [(1, u'TOTO', 19)]
Program B :
--
Same code with 'sqlite:///test19.db'.
== result []
Do you have any suggestions ?
Anddi
--~--~-~--~~~---~--~~
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: SQLAlchemy test suite - no success/failure exit code
Michael go into python and type: Michael from pysqlite2 import dbapi2 Michael dbapi2.sqlite_version Well, that failed: $ /tmp/python-buildbot/local/bin/python Python 2.6a0 (trunk:54421, Mar 17 2007, 11:17:17) [GCC 4.0.0 (Apple Computer, Inc. build 5026)] on darwin Type help, copyright, credits or license for more information. from pysqlite2 import dbapi2 Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named pysqlite2 but pysqlite3 is there: $ /tmp/python-buildbot/local/bin/python Python 2.6a0 (trunk:54421, Mar 17 2007, 11:17:17) [GCC 4.0.0 (Apple Computer, Inc. build 5026)] on darwin Type help, copyright, credits or license for more information. from pysqlite3 import dbapi2 Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named pysqlite3 from sqlite3 import dbapi2 dbapi2.sqlite_version '3.1.3' Does that help? Forgive me, I really have no idea how much of sqlite comes with Python (is it just pysqlite?) or what it uses if there is another version installed on the machine. Skip --~--~-~--~~~---~--~~ 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: SQLAlchemy test suite - no success/failure exit code
yes 3.1.3 is a fairly old version (from February 2005), the unit tests are assuming at least version 3.2.3 of sqlite. but youre best off with the very latest 3.3.13. On Mar 17, 2007, at 4:25 PM, [EMAIL PROTECTED] wrote: Michael go into python and type: Michael from pysqlite2 import dbapi2 Michael dbapi2.sqlite_version Well, that failed: $ /tmp/python-buildbot/local/bin/python Python 2.6a0 (trunk:54421, Mar 17 2007, 11:17:17) [GCC 4.0.0 (Apple Computer, Inc. build 5026)] on darwin Type help, copyright, credits or license for more information. from pysqlite2 import dbapi2 Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named pysqlite2 but pysqlite3 is there: $ /tmp/python-buildbot/local/bin/python Python 2.6a0 (trunk:54421, Mar 17 2007, 11:17:17) [GCC 4.0.0 (Apple Computer, Inc. build 5026)] on darwin Type help, copyright, credits or license for more information. from pysqlite3 import dbapi2 Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named pysqlite3 from sqlite3 import dbapi2 dbapi2.sqlite_version '3.1.3' Does that help? Forgive me, I really have no idea how much of sqlite comes with Python (is it just pysqlite?) or what it uses if there is another version installed on the machine. Skip --~--~-~--~~~---~--~~ 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: server_side_cursors
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: server_side_cursors
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: server_side_cursors
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: server_side_cursors
sorry, i meant cursor.description, not cursor.metadata. --~--~-~--~~~---~--~~ 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: server_side_cursors
SQLAlchemy's result wrapper, ResultProxy, then calls:
metadata = cursor.metadata
My question was why doesn't ResultProxy use the sqlalchemy metadata I
defined when I defined the sqlalchemy Table?
to psycopg2 versions, PG setup, or what. if we can determine its a
psycopg2 version issue, then everyone can just upgrade.
which version are you using?
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
-~--~~~~--~~--~--~---
