Hi,
I've just upgraded to 0.3.7, and when the combined table/column name
is at least 30 characters I get an error from the mapper like this:
sqlalchemy.exceptions.NoSuchColumnError: Could not locate column in
row for column 'Column(u'EventLastCancellationDate',MSDate())'
Is this a problem with
I want to get recipes which belongs to a particular category and having
a particular flag. So I need both joins recipe-category and recipe-flag.
Michael Bayer napsal(a):
On Apr 30, 2007, at 8:40 AM, ml wrote:
Hi!
I have 2 relations:
- recipes-categories (M:N)
- recipes-flags (M:N)
Hi,
I have a postgres function returning a set of records (using RETURN
NEXT). While calling the function like this:
tasklist = func.get_tasklist(engine=engine).execute() # is this the
correct way?
I am getting this error:
SQLError: ('(ProgrammingError) set-valued function called in context
To add a little more info, 0.3.6 generates:
SELECT [T_Event].[EventLastCancellationDate] AS
[T_Event_EventLastCancell_8ab9]
whereas 0.3.7 generates
[T_Event].[EventLastCancellationDate] AS
[T_Event_EventLastCancellationDate]
From what I can find, column names can be up to 128 chars in SQL
SA is now doing no column truncation for MS-SQL, as we have not
placed any limit within the MS-SQL dialects. previously, SA was
truncating all identifiers to 30 characters for all dialects
(including those that had much larger limitations), and it would
search for these truncated names
On May 1, 2007, at 4:42 AM, ml wrote:
I want to get recipes which belongs to a particular category and
having
a particular flag. So I need both joins recipe-category and recipe-
flag.
ah. in that case you dont want query.join(x).join(y), you want the
second join to still be
On May 1, 2007, at 7:06 AM, Sanjay wrote:
Hi,
I have a postgres function returning a set of records (using RETURN
NEXT). While calling the function like this:
tasklist = func.get_tasklist(engine=engine).execute() # is this the
correct way?
looks fine to me. for the rest of it, im
On May 1, 2007, at 7:50 AM, Graham Stratton wrote:
To add a little more info, 0.3.6 generates:
SELECT [T_Event].[EventLastCancellationDate] AS
[T_Event_EventLastCancell_8ab9]
whereas 0.3.7 generates
[T_Event].[EventLastCancellationDate] AS
[T_Event_EventLastCancellationDate]
From
Huh? I thought this was something you wantedI guess I misunderstood the
thread.
I don't have time to do this by myself. If someone wants to pick it up and
run with it, I'll be happy to work with you and to host the buildslave here,
or I'm OK with just letting the thing die, too.
On
s/DBAPI/DBlib/
On 5/1/07, Rick Morrison [EMAIL PROTECTED] wrote:
The label-truncation code is fine. The issue isn't SA. It's the DBAPI that
pymssql rides on top of...identifier limit is 30
chars, is deprecated by Microsoft, it will never be fixed.
Try pyodbc, which has no such limitation.
I tried the following:
import sqlalchemy as SA
md_dbA=SA.BoundMetaData('dbA')
tbl_dbAtbl=SA.Table('dbAtbl',md_dbA,autoload=True)
SA.text(ATTACH DATABASE 'C:Temp\dbB.db' as dbB_db)
tbl_dbBtbl=SA.Table('dbB_db.dbBtbl',md_dbA,schema='dbB_db',autoload=True)
===
The code fails on the line
I tried the following:
import sqlalchemy as SA
md_dbA=SA.BoundMetaData('dbA')
tbl_dbAtbl=SA.Table('dbAtbl',md_dbA,autoload=True)
SA.text(ATTACH DATABASE 'C:Temp\dbB.db' as dbB_db)
tbl_dbBtbl=SA.Table('dbB_db.dbBtbl',md_dbA,schema='dbB_db',autoload=True)
===
The code fails on the line
On May 1, 2007, at 11:18 AM, Rick Morrison wrote:
The label-truncation code is fine. The issue isn't SA. It's the
DBAPI that pymssql rides on top of...identifier limit is 30 chars,
is deprecated by Microsoft, it will never be fixed.
Try pyodbc, which has no such limitation.
OK well,
The underlying DBlib limits *all* identifier names, including column names
to 30 chars anyway, so no issue there.
Where does the character limit go in the dialect? Can I follow Oracle as an
example?
On 5/1/07, Michael Bayer [EMAIL PROTECTED] wrote:
On May 1, 2007, at 11:18 AM, Rick
Rick Huh? I thought this was something you wantedI guess I
Rick misunderstood the thread.
Rick I don't have time to do this by myself. If someone wants to pick
Rick it up and run with it, I'll be happy to work with you and to host
Rick the buildslave here, or I'm OK
Hi,
I've found SA/MSSQL is mostly stable now. I do have a few bugs
outstanding, and I'm sure I'll need to dive into the source code again
in the future, but it's comparably stable to the rest of SA.
The unit test failures are right down, at least on Windows. I haven't
tested PyODBC on other
I wouldn't think that pysqlite being installed on the master is an issue:
the tests would be run on the slave and in the slave environment.
I think that Skip's sqlite issue is more likely one of:
a) using the included pysqlite in Python 2.5+ and issues with that
or
The 0.3.7 bug is my fault, I checked in the changes without testing on
pyodbc. Didn't know that Mike would cut 0.3.7 the very next day! Guess I'll
get to use that buildslave for something after all...
Paul, I wasn't aware of scope_identity() not working on pyodbc, I checked it
in because it was
Good to hear that adodbapi is going to get some loving.
Here's a brain dump on Unix + ODBC:
There are a lot of commercial UNIX ODBC interfaces of varying
quality out there; I'm not familiar with any of them.
As usual with open source, there's not one but two options for free ODBC
software,
On May 1, 2007, at 3:02 AM, Andreas Jung wrote:
ResultProxy_instance.cursor.description returns the 7-tuple as
defined in the Python DB API containing information about the
result set.
The type_code (the second element of each tuple) is an integer:
(('id', 20, 5, 8, None, None,
Rick a) using the included pysqlite in Python 2.5+ and issues with
Rick that
Rick b) conflict with the sqlite library that ships with OSX
Rick and out of those, I would bet (b). The sqlite that ships for
Rick Coredata with OSX Tiger is old, and I think that SA
21 matches
Mail list logo
