[sqlalchemy] Re: Weak Referencing Session
Hi, that the identity map within the Session again becomes weak referencing, the way it used to be back in 0.2 and part of 0.3. +0 from me. It sounds like a sensible change, but I only use short-lived sessions in web apps, so it makes little difference to me. Paul --~--~-~--~~~---~--~~ 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: getattr(myresults,ColumName) vs myresults[ColumnName]
On Sep 12, 2007, at 12:03 AM, Lukasz Szybalski wrote: Currently when you get a record via sqlalachemy you need to take a look at the docs overview (0.4 docs are much better than 0.3s); theres two very different ways to get a record in sqlalchemy. using a SQL expression, you get the exact dictionary like structure you're looking for (much faster than ORM too). --~--~-~--~~~---~--~~ 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: Many-to-Many, Column not available
On Sep 11, 2007, at 7:31 PM, KyleJ wrote: I have three rows in the base_table (id's 1-3) and two rows in the relations table. So the row with id 1 in the base_table is linked to the other two rows view two entries in the relations table: INSERT INTO relations (toObj, fromObj) VALUES (2, 1); INSERT INTO relations (toObj, fromObj) VALUES (3, 1); thats an error in your setup right there. youre saying that fromObj is the primary key column for Relation. But right there, the same integer id (1) is being inserted twice. do you mean instaed that fromObj/toObj should compose a composite primary key perhaps ? --~--~-~--~~~---~--~~ 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] Portable exceptions in SA
Hello everybody, I was wondering why neither DBAPI nor SA define standard exceptions like Duplicate key error. It seems to be no portable way to catch this situations and give user more sensible error messages than just We are failed to insert a new record. And using exception information to generate error messages make it even more confusing for regular (non-Pythonic :) ) people. Since SA dialects deal with implementation details wouldn't it be natural to have them translate DBAPI exceptions to something more usable as well? Cheers --~--~-~--~~~---~--~~ 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: Portable exceptions in SA
we do want to get error code availability into our exception classes (still waiting for any DBAPIs besides psycopg2 to provide these with no parsing requirement), and there are some cases where we want to evaulate an exception to discern it from others (such as detecting database timeouts), but the level of magic (i.e., you get some magic SQLAlchemy error which you cant google for, has less fine- grained detail than the actual DB error, user database errors now become SQLAlchemy issues) as well as the huge maintenance problem this approach would bring (DBAPIs are totally inconsistent, changing all the time, etc) would be a lot more trouble than its worth, as far as it being built-in, default behavior. The number of exception concepts that are truly portable is relatively low (like duplicate key), so any such functionality I'd say would have to remain as an electable. On Sep 12, 2007, at 11:30 AM, askel wrote: Hello everybody, I was wondering why neither DBAPI nor SA define standard exceptions like Duplicate key error. It seems to be no portable way to catch this situations and give user more sensible error messages than just We are failed to insert a new record. And using exception information to generate error messages make it even more confusing for regular (non-Pythonic :) ) people. Since SA dialects deal with implementation details wouldn't it be natural to have them translate DBAPI exceptions to something more usable as well? Cheers --~--~-~--~~~---~--~~ 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: db autogenerated pks?
Still have problems...
if i change:
t = sa.Table(Machines, metadata, autoload=True)
to:
t = sa.Table(Rpm_MacchineConfig, metadata,
sa.Column('uId', sa.databases.mssql.MSUniqueIdentifier,
primary_key=True),
autoload=False)
i have:
sqlalchemy.exceptions.DBAPIError: (ProgrammingError) ('42000',
[42000] [Microso
ft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near
')'. (102)) u'INSERT INTO [Rpm_MacchineConfig] () VALUES ()' []
and if i put autoload= True, like this:
t = sa.Table(Rpm_MacchineConfig, metadata,
sa.Column('uId', sa.databases.mssql.MSUniqueIdentifier,
primary_key=True),
autoload=True)
i have this:
sqlalchemy.exceptions.DBAPIError: (IntegrityError) ('23000', [23000]
[Microsoft
][ODBC SQL Server Driver][SQL Server]Impossible to insert NULL value
into column 'uId' on table 'dbtests.dbo.Rpm_MachineConfig'.The column
does not support NULL values (515); [01000] [Microsoft][O
DBC SQL Server Driver][SQL Server]Instruction interrupted. (3621)) u
'INSERT INTO [Rpm_MacchineConfig] (nome, nodo, descrizione) VALUES
(?, ?, ?)' ['MARIO', 'FI', None ]
Any hint before i start changing my table design? I'm a newbie on
sqlalchemy so i'm probably missing something...
thanks
FP
On 12 Set, 02:18, KyleJ [EMAIL PROTECTED] wrote:
You probably need to override the autoloaded primary key
column:http://www.sqlalchemy.org/docs/04/metadata.html#metadata_tables_refle...
Specify the type with MSUniqueIdentifier from
sqlalchemy.databases.mssql
On Sep 11, 9:01 am, Smoke [EMAIL PROTECTED] wrote:
Hi All,
I'm new to sqlalchemy and was checking if i can introduce it into some
of my projects... I have some database ( sql server ) tables with
MSUniqueidenfier columns set as PK and with newid() as default
values...
So, if i try to map this table into a class,save a new record and
flush, then i have errors because it says that column doesn't support
NULL values..
Is there any option i'm missing that can make me exclude this PK from
the INSERT query or somehow tell sqlalchemy that this pk column value
is autogenerated by the database?
thanks,
FP
P.S.:
My code is something very simple... like this:
t = sa.Table(Machines, metadata, autoload=True)
Session = sessionmaker(bind=db, autoflush=False, transactional=False)
class Machine(object):
pass
session = Session()
sa.orm.mapper(Machine, t)#, exclude_properties=['uId'])
m = Machine()
nm = Machine()
nm.name, nm.node = Mac1, P
session.save(nm)
session.flush()
--~--~-~--~~~---~--~~
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: Portable exceptions in SA
Michael, Thank you for replying. I think just making few exception classes available would be enough to make some progress. May be some backends would use them without involving too much work and magic. At least people would know there is better way. Even if it would be just psycopg2 for beginning it is still something more useful than what we have now. I'd say key violation, null value, transaction timeout, connection failure/timeout are pretty common to be part of SA API. On Sep 12, 11:46 am, Michael Bayer [EMAIL PROTECTED] wrote: we do want to get error code availability into our exception classes (still waiting for any DBAPIs besides psycopg2 to provide these with no parsing requirement), and there are some cases where we want to evaulate an exception to discern it from others (such as detecting database timeouts), but the level of magic (i.e., you get some magic SQLAlchemy error which you cant google for, has less fine- grained detail than the actual DB error, user database errors now become SQLAlchemy issues) as well as the huge maintenance problem this approach would bring (DBAPIs are totally inconsistent, changing all the time, etc) would be a lot more trouble than its worth, as far as it being built-in, default behavior. The number of exception concepts that are truly portable is relatively low (like duplicate key), so any such functionality I'd say would have to remain as an electable. On Sep 12, 2007, at 11:30 AM, askel wrote: Hello everybody, I was wondering why neither DBAPI nor SA define standard exceptions like Duplicate key error. It seems to be no portable way to catch this situations and give user more sensible error messages than just We are failed to insert a new record. And using exception information to generate error messages make it even more confusing for regular (non-Pythonic :) ) people. Since SA dialects deal with implementation details wouldn't it be natural to have them translate DBAPI exceptions to something more usable as well? Cheers --~--~-~--~~~---~--~~ 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] django + sqlalchemy = ?
Cross-posted to django sqlalchemy lists What is the state of SQLAlchemy integration with Django? I saw somewhere that it was possible to use them together, but the author didn't provide any details, and the SQLAlchemy branch of Django hasn't had any commits since late last year. Was the original goal of the branch [1] too aggressive? Thanks in advance. -Ken [1] Integrating Django and SQLAlchemy, Aug 29, 2006: http://groups.google.com/group/django-developers/browse_thread/thread/5149e1c60dc65bff --~--~-~--~~~---~--~~ 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: Portable exceptions in SA
ANSI defines the SQLSTATE error codes for portable errors. I think there is SQLSTATE support in most of the databases SQLAlchemy supports (but none in SQLite that I can find), and the error code should be available via db-api either directly (pyscopg2, mysql-python, at minimum) or can parsed out of the text error message. SQLSTATE is a structured 5 char string that embeds the class of error. You could, say, examine just the first two chars to find out that the error is some kind of constraint violation, or consider the whole code to see that it's a specific duplicate key error. But like everything else sql, database vendors seem to vary in their support. Not all database errors are mapped or even mappable at all to a defined condition in the sql spec. So even the standard SQLSTATE codes don't seem to be useful in practice as much more than a hint, albeit a much better hint than anything else available. That said, I'm +1 on having SQLSTATE and the error message string available as standard attributes on the DBAPIError wrapper. I'm -1 on also providing attribute access to the database's internal error number or code. I don't think I'd be enthusiastic about any proposal to actually modify the type of exception based on the SQLSTATE or error code, at least not until the magic day when all databases raise consistent errors. Until then, shadowing the db-api exception type as we do now feels like the path of least surprise. Michael Bayer wrote: we do want to get error code availability into our exception classes (still waiting for any DBAPIs besides psycopg2 to provide these with no parsing requirement), and there are some cases where we want to evaulate an exception to discern it from others (such as detecting database timeouts), but the level of magic (i.e., you get some magic SQLAlchemy error which you cant google for, has less fine- grained detail than the actual DB error, user database errors now become SQLAlchemy issues) as well as the huge maintenance problem this approach would bring (DBAPIs are totally inconsistent, changing all the time, etc) would be a lot more trouble than its worth, as far as it being built-in, default behavior. The number of exception concepts that are truly portable is relatively low (like duplicate key), so any such functionality I'd say would have to remain as an electable. On Sep 12, 2007, at 11:30 AM, askel wrote: Hello everybody, I was wondering why neither DBAPI nor SA define standard exceptions like Duplicate key error. It seems to be no portable way to catch this situations and give user more sensible error messages than just We are failed to insert a new record. And using exception information to generate error messages make it even more confusing for regular (non-Pythonic :) ) people. Since SA dialects deal with implementation details wouldn't it be natural to have them translate DBAPI exceptions to something more usable as well? Cheers --~--~-~--~~~---~--~~ 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: db autogenerated pks?
SQL Server provides no facilities for retrieving a GUID key after an insert
-- it's not a true autoincrementing key. The MSSQL driver for SA uses either
@@IDENTITY or SCOPE_IDENTITY() to retreive the most-recently inserted
autoincrement value, but there is no such facility for getting GUID keys.
SA provides a mechanism called passive default to handle these kinds of
things. What it does under the covers, or what you can do explicitly without
it is:
a) first call newid() to get the new GUID
b) then do the insert using the GUID value as a normal attribute
My personal opinion is that GUID keys are over-utilized, and there are
usually better alternatives that will perform better overall, and will not
make you swim upstream with SA. Here's a link to an article about an
alternate scheme to get rid of GUID keys that talks about performance
implications, I'm sure you can find more if you look:
http://www.sql-server-performance.com/articles/per/guid_performance_p1.aspx
Rick
On 9/12/07, Smoke [EMAIL PROTECTED] wrote:
Still have problems...
if i change:
t = sa.Table(Machines, metadata, autoload=True)
to:
t = sa.Table(Rpm_MacchineConfig, metadata,
sa.Column('uId', sa.databases.mssql.MSUniqueIdentifier,
primary_key=True),
autoload=False)
i have:
sqlalchemy.exceptions.DBAPIError: (ProgrammingError) ('42000',
[42000] [Microso
ft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near
')'. (102)) u'INSERT INTO [Rpm_MacchineConfig] () VALUES ()' []
and if i put autoload= True, like this:
t = sa.Table(Rpm_MacchineConfig, metadata,
sa.Column('uId', sa.databases.mssql.MSUniqueIdentifier,
primary_key=True),
autoload=True)
i have this:
sqlalchemy.exceptions.DBAPIError: (IntegrityError) ('23000', [23000]
[Microsoft
][ODBC SQL Server Driver][SQL Server]Impossible to insert NULL value
into column 'uId' on table 'dbtests.dbo.Rpm_MachineConfig'.The column
does not support NULL values (515); [01000] [Microsoft][O
DBC SQL Server Driver][SQL Server]Instruction interrupted. (3621)) u
'INSERT INTO [Rpm_MacchineConfig] (nome, nodo, descrizione) VALUES
(?, ?, ?)' ['MARIO', 'FI', None ]
Any hint before i start changing my table design? I'm a newbie on
sqlalchemy so i'm probably missing something...
thanks
FP
On 12 Set, 02:18, KyleJ [EMAIL PROTECTED] wrote:
You probably need to override the autoloaded primary key column:
http://www.sqlalchemy.org/docs/04/metadata.html#metadata_tables_refle...
Specify the type with MSUniqueIdentifier from
sqlalchemy.databases.mssql
On Sep 11, 9:01 am, Smoke [EMAIL PROTECTED] wrote:
Hi All,
I'm new to sqlalchemy and was checking if i can introduce it into some
of my projects... I have some database ( sql server ) tables with
MSUniqueidenfier columns set as PK and with newid() as default
values...
So, if i try to map this table into a class,save a new record and
flush, then i have errors because it says that column doesn't support
NULL values..
Is there any option i'm missing that can make me exclude this PK from
the INSERT query or somehow tell sqlalchemy that this pk column value
is autogenerated by the database?
thanks,
FP
P.S.:
My code is something very simple... like this:
t = sa.Table(Machines, metadata, autoload=True)
Session = sessionmaker(bind=db, autoflush=False, transactional=False)
class Machine(object):
pass
session = Session()
sa.orm.mapper(Machine, t)#, exclude_properties=['uId'])
m = Machine()
nm = Machine()
nm.name, nm.node = Mac1, P
session.save(nm)
session.flush()
--~--~-~--~~~---~--~~
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: Portable exceptions in SA
I'd prefer to catch some more specific exceptions even though they'd never be generated by most backends rather than decoding SQLSTATE and use if-s or other dispatching method based on what this variable/ exception attribute holds. On Sep 12, 1:17 pm, jason kirtland [EMAIL PROTECTED] wrote: ANSI defines the SQLSTATE error codes for portable errors. I think there is SQLSTATE support in most of the databases SQLAlchemy supports (but none in SQLite that I can find), and the error code should be available via db-api either directly (pyscopg2, mysql-python, at minimum) or can parsed out of the text error message. SQLSTATE is a structured 5 char string that embeds the class of error. You could, say, examine just the first two chars to find out that the error is some kind of constraint violation, or consider the whole code to see that it's a specific duplicate key error. But like everything else sql, database vendors seem to vary in their support. Not all database errors are mapped or even mappable at all to a defined condition in the sql spec. So even the standard SQLSTATE codes don't seem to be useful in practice as much more than a hint, albeit a much better hint than anything else available. That said, I'm +1 on having SQLSTATE and the error message string available as standard attributes on the DBAPIError wrapper. I'm -1 on also providing attribute access to the database's internal error number or code. I don't think I'd be enthusiastic about any proposal to actually modify the type of exception based on the SQLSTATE or error code, at least not until the magic day when all databases raise consistent errors. Until then, shadowing the db-api exception type as we do now feels like the path of least surprise. Michael Bayer wrote: we do want to get error code availability into our exception classes (still waiting for any DBAPIs besides psycopg2 to provide these with no parsing requirement), and there are some cases where we want to evaulate an exception to discern it from others (such as detecting database timeouts), but the level of magic (i.e., you get some magic SQLAlchemy error which you cant google for, has less fine- grained detail than the actual DB error, user database errors now become SQLAlchemy issues) as well as the huge maintenance problem this approach would bring (DBAPIs are totally inconsistent, changing all the time, etc) would be a lot more trouble than its worth, as far as it being built-in, default behavior. The number of exception concepts that are truly portable is relatively low (like duplicate key), so any such functionality I'd say would have to remain as an electable. On Sep 12, 2007, at 11:30 AM, askel wrote: Hello everybody, I was wondering why neither DBAPI nor SA define standard exceptions like Duplicate key error. It seems to be no portable way to catch this situations and give user more sensible error messages than just We are failed to insert a new record. And using exception information to generate error messages make it even more confusing for regular (non-Pythonic :) ) people. Since SA dialects deal with implementation details wouldn't it be natural to have them translate DBAPI exceptions to something more usable as well? Cheers --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
