[sqlalchemy] Re: nullable=False by default
But I'm supposed that the generation function of autoincrement only works when the field is NULL or there is an integer, so this fails on fields with a string empty. On Jul 7, 8:06 am, Kless [EMAIL PROTECTED] wrote: Yes, I read it. The integer columns with the primary key flag set are not being autoincremented, after of the Column subclass. On Jul 7, 3:45 am, Michael Bayer [EMAIL PROTECTED] wrote: On Jul 6, 2008, at 7:06 PM, Kless wrote: I think that there is a bug. autoincrement doesn't works with *default=''* Any solution to this problem? the docs for autoincrement need to be read closely. This flag only applies to Integer columns with the primary key flag set. I'm not sure what interaction it would be expected to have with default in any case (default is all you need if you have a custom default generation function). --~--~-~--~~~---~--~~ 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] query.filter and entity_name
Hi, I'm having trouble using entity_name. I have two mappers for the same class, one of them having an entity_name=legacy. If I do a query with the legacy mapper, I cannot figure how to filter on properties. Ex: session.query(MyClass, entity_name='legacy').filter( MyClass.arelationprop.has( criterions )) In this case, the table from the default mapper is always getting in the way. I think I am not using properly the alternate mapper, but cannot find any example. Thanks a lot, Christophe --~--~-~--~~~---~--~~ 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] problem with SHOW command
Hi.
I'm having strange problems when I execute a SHOW command with PostgreSQL.
from sqlalchemy import create_engine, sql, __version__
print __version__
URL = 'postgres://xxx:[EMAIL PROTECTED]/xxx'
db = create_engine(URL, echo=True)
conn = db.connect()
query = sql.text('SHOW CLIENT_ENCODING')
r = conn.execute(query)
print r.scalar()
0.4.6
Traceback (most recent call last):
File postgres_show_bug.py, line 11, in module
print r.scalar()
File /var/lib/python-support/python2.5/sqlalchemy/engine/base.py,
line 1661, in scalar
self.connection._handle_dbapi_exception(e, None, None, self.cursor)
File /var/lib/python-support/python2.5/sqlalchemy/engine/base.py,
line 942, in _handle_dbapi_exception
raise exceptions.DBAPIError.instance(statement, parameters, e,
connection_invalidated=is_disconnect)
sqlalchemy.exceptions.InterfaceError: (InterfaceError) cursor already
closed None None
What's the problem?
If I execute the query directly with psycopg2, there are no errors.
Thanks Manlio Perillo
--~--~-~--~~~---~--~~
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: transactions with multiple potential constraint violations
Thanks Mike! Your last suggestion was the best (ans easiest) solution, I guess I just needed someone to point that out to me ;-) Since I want the whole transaction to either succeed or fail, there's no need to use SAVEPOINTs. Cheers, Simon On 3 Jul., 19:55, Michael Bayer [EMAIL PROTECTED] wrote: On Jul 3, 2008, at 1:09 PM, Simon wrote: Hi all, I have a transactional session which save()s multiple objects to multiple tables where each object potentially violates a unique primary key or just a unique key constraint. At flush() time, MySQL returns an IntegrityError which specifies the value of the offending key and the key's number within its table (i.e. first key, second key...), but I cannot from this information figure out which of my objects is the culprit. Any suggestions on how to solve this problem? Ideally, I would like to rollback() the whole transaction when such an error occurs, regenerate the keys on the offending object, and repeat until commit() succeeds. use SQLA 0.5 if you'd like to rollback() a session and continue using the objects within. Read throughhttp://www.sqlalchemy.org/docs/05/session.html#unitofwork_using_rolling and elsewhere to see what the SQLA contract is regarding sessions, errors and rolling back. It's also worthwhile to give SAVEPOINT a try, which allows partial transactions to commit and is described athttp://www.sqlalchemy.org/docs/05/session.html#unitofwork_managing_sa... . In particular, some databases such as Postgres do not allow the transaction to continue if an integrity error is raised, necessitating the use of SAVEPOINT, or just querying the table beforehand (which is the traditional approach to this problem). --~--~-~--~~~---~--~~ 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: problem with SHOW command
Manlio Perillo ha scritto:
Hi.
I'm having strange problems when I execute a SHOW command with PostgreSQL.
from sqlalchemy import create_engine, sql, __version__
print __version__
URL = 'postgres://xxx:[EMAIL PROTECTED]/xxx'
db = create_engine(URL, echo=True)
conn = db.connect()
query = sql.text('SHOW CLIENT_ENCODING')
r = conn.execute(query)
print r.scalar()
I've no problem:
0.3.10
2008-07-07 15:22:29,161 INFO sqlalchemy.engine.base.Engine.0x..d4 SHOW
CLIENT_ENCODING
2008-07-07 15:22:29,161 INFO sqlalchemy.engine.base.Engine.0x..d4 {}
UTF8
do you have the same problem with the fetchall()?
r = conn.execute( 'SHOW CLIENT_ENCODING' )
print r.fetchall()
Glauco
--
++
Glauco Uri
glauco(at)sferacarta.com
Sfera Carta Software® info(at)sferacarta.com
Via Bazzanese,69 Casalecchio di Reno(BO) - Tel. 051591054
++
--~--~-~--~~~---~--~~
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: result as the dict()
MyBase = type(MyBase, (Base, MyMixin), {})
Is this any different than just doing
class MyBase(Base, MyMixin): pass
?
--~--~-~--~~~---~--~~
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: nullable=False by default
On Jul 7, 2008, at 3:06 AM, Kless wrote: Yes, I read it. The integer columns with the primary key flag set are not being autoincremented, after of the Column subclass. what database ? Oracle and Firebird require a Sequence to be specified. --~--~-~--~~~---~--~~ 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: nullable=False by default
On Jul 7, 2008, at 3:10 AM, Kless wrote: But I'm supposed that the generation function of autoincrement only works when the field is NULL or there is an integer, so this fails on fields with a string empty. im not sure offhand what an empty string would produce since I'd have to check what we're doing to detect no value present. But I would hope that if the string value went through, it would raise an error on the DB side (so this impies you might be using SQLite). --~--~-~--~~~---~--~~ 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: nullable=False by default
Yes, it's SQLite. I use it into the development. On Jul 7, 4:06 pm, Michael Bayer [EMAIL PROTECTED] wrote: On Jul 7, 2008, at 3:10 AM, Kless wrote: But I'm supposed that the generation function of autoincrement only works when the field is NULL or there is an integer, so this fails on fields with a string empty. im not sure offhand what an empty string would produce since I'd have to check what we're doing to detect no value present. But I would hope that if the string value went through, it would raise an error on the DB side (so this impies you might be using SQLite). --~--~-~--~~~---~--~~ 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: query.filter and entity_name
It's currently preferred if you didn't use entity_name since it works quite poorly and even worse in 0.5, and we'd like to remove it - it has built-in undefined behavior in that its not determined which set of attribute instrumentation gets applied to the class. This feature is an artifact of Hibernate which we copied at some point but doesn't apply well to Python where subclassing does not place a significant structural burden on code (and multiple inheritance makes it even less burdensome). Mapping to individual subclases is much more straightforward - its the difference between your instance which is of class A plus magic entity name attribue B, versus, your instance is of class B subclassing A. The object has state which represents the entity_name in either case. We haven't yet removed entity_name from 0.5 because I'm waiting for someone to have a truly compelling argument for it. On Jul 7, 2008, at 6:45 AM, Christophe de VIENNE wrote: Hi, I'm having trouble using entity_name. I have two mappers for the same class, one of them having an entity_name=legacy. If I do a query with the legacy mapper, I cannot figure how to filter on properties. Ex: session.query(MyClass, entity_name='legacy').filter( MyClass.arelationprop.has( criterions )) In this case, the table from the default mapper is always getting in the way. I think I am not using properly the alternate mapper, but cannot find any example. Thanks a lot, Christophe --~--~-~--~~~---~--~~ 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: problem with SHOW command
Glauco ha scritto:
Manlio Perillo ha scritto:
Hi.
I'm having strange problems when I execute a SHOW command with PostgreSQL.
from sqlalchemy import create_engine, sql, __version__
print __version__
URL = 'postgres://xxx:[EMAIL PROTECTED]/xxx'
db = create_engine(URL, echo=True)
conn = db.connect()
query = sql.text('SHOW CLIENT_ENCODING')
r = conn.execute(query)
print r.scalar()
I've no problem:
0.3.10
2008-07-07 15:22:29,161 INFO sqlalchemy.engine.base.Engine.0x..d4 SHOW
CLIENT_ENCODING
2008-07-07 15:22:29,161 INFO sqlalchemy.engine.base.Engine.0x..d4 {}
UTF8
What version of SQLAlchemy/PostgreSQL/psycopg2 are you using?
I'm using (on Debian Lenny):
* SQLAlchemy 0.4.6-1
* PostgreSQL 8.3.3-1
* psycopg2 2.0.7-4
do you have the same problem with the fetchall()?
r = conn.execute( 'SHOW CLIENT_ENCODING' )
print r.fetchall()
It's the same.
Thanks Manlio Perillo
--~--~-~--~~~---~--~~
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: nullable=False by default
then its probably inserting your blank string into the column. SQLA doesn't want to get too much in the way of the natural features of the database in use. On Jul 7, 2008, at 11:09 AM, Kless wrote: Yes, it's SQLite. I use it into the development. On Jul 7, 4:06 pm, Michael Bayer [EMAIL PROTECTED] wrote: On Jul 7, 2008, at 3:10 AM, Kless wrote: But I'm supposed that the generation function of autoincrement only works when the field is NULL or there is an integer, so this fails on fields with a string empty. im not sure offhand what an empty string would produce since I'd have to check what we're doing to detect no value present. But I would hope that if the string value went through, it would raise an error on the DB side (so this impies you might be using SQLite). --~--~-~--~~~---~--~~ 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: query.filter and entity_name
On Monday 07 July 2008 18:10:19 Michael Bayer wrote: It's currently preferred if you didn't use entity_name since it works quite poorly and even worse in 0.5, and we'd like to remove it - it has built-in undefined behavior in that its not determined which set of attribute instrumentation gets applied to the class. i had some idea about this instrumentation stuff... it's theoretical as i didnt have time to try it - and since i'm sort-of out of job i probably wouldnt have a chance to try it. but anyway. seems sooner or later one ends in need of multiple aspects requireing instrumentation, e.g. DB-backend, dependency-calculations (trelis or similar), automatic typing/validation, temporal view (single version vs history of versions of one object vs history of many objects of same type), etc. i was thinking about having some super-instrumentation, which contains all the instrumentations, and one can choose which one(s) to apply at hand. This might be a bit strange; most of the instrumentations would be applied at same time, probably in some preset order. i'm not sure how exactly one could switch between DB-entity-instrumentations, but say right now i need to switch between different temporal views, so there should be a way - via default context, or special attribute/subattribute or something. it's just an idea - which has been probably invented long time ago somewhere else. The whole point is to have everything attached to same class - which may or may not be useable/preferable. Probably in most cases an aspect can be added without needing class-awareness. This feature is an artifact of Hibernate which we copied at some point but doesn't apply well to Python where subclassing does not place a significant structural burden on code (and multiple inheritance makes it even less burdensome). Mapping to individual subclases is much more straightforward - its the difference between your instance which is of class A plus magic entity name attribue B, versus, your instance is of class B subclassing A. The object has state which represents the entity_name in either case. can u have 2 classes with 2 different mappers over same table? i guess yes? then its really not needed. We haven't yet removed entity_name from 0.5 because I'm waiting for someone to have a truly compelling argument for it. On Jul 7, 2008, at 6:45 AM, Christophe de VIENNE wrote: Hi, I'm having trouble using entity_name. I have two mappers for the same class, one of them having an entity_name=legacy. If I do a query with the legacy mapper, I cannot figure how to filter on properties. Ex: session.query(MyClass, entity_name='legacy').filter( MyClass.arelationprop.has( criterions )) In this case, the table from the default mapper is always getting in the way. I think I am not using properly the alternate mapper, but cannot find any example. Thanks a lot, Christophe --~--~-~--~~~---~--~~ 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: nullable=False by default
You have reason. I checked it with MySQL and it works ok. So here I have a lesson learned: use the same RDBMS on developing. Thanks Michael. On Jul 7, 4:50 pm, Michael Bayer [EMAIL PROTECTED] wrote: then its probably inserting your blank string into the column. SQLA doesn't want to get too much in the way of the natural features of the database in use. On Jul 7, 2008, at 11:09 AM, Kless wrote: Yes, it's SQLite. I use it into the development. On Jul 7, 4:06 pm, Michael Bayer [EMAIL PROTECTED] wrote: On Jul 7, 2008, at 3:10 AM, Kless wrote: But I'm supposed that the generation function of autoincrement only works when the field is NULL or there is an integer, so this fails on fields with a string empty. im not sure offhand what an empty string would produce since I'd have to check what we're doing to detect no value present. But I would hope that if the string value went through, it would raise an error on the DB side (so this impies you might be using SQLite). --~--~-~--~~~---~--~~ 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] synonyms question
Hello
To override attribute behavior the 0.5 doc gives this example:
class MyAddress(object):
def _set_email(self, email):
self._email = email
def _get_email(self):
return self._email
email = property(_get_email, _set_email)
mapper(MyAddress, addresses_table, properties = {
'email':synonym('_email', map_column=True)
})
What won't work if I just set the python property and don't use the
synonym func:
mapper(MyAddress, addresses_table)
What difference does it make? I couldn't find an explanation in the doc.
Sorry if that's a dumb question!
Thanks,
--
Eric
--~--~-~--~~~---~--~~
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: synonyms question
On Jul 7, 2008, at 3:29 PM, Eric Lemoine wrote:
Hello
To override attribute behavior the 0.5 doc gives this example:
class MyAddress(object):
def _set_email(self, email):
self._email = email
def _get_email(self):
return self._email
email = property(_get_email, _set_email)
mapper(MyAddress, addresses_table, properties = {
'email':synonym('_email', map_column=True)
})
What won't work if I just set the python property and don't use the
synonym func:
mapper(MyAddress, addresses_table)
What difference does it make? I couldn't find an explanation in the
doc.
Sorry if that's a dumb question!
without synonym(), just add _email:addresses_table.c.email to your
mapper properties dict so that the email name is made available.
--~--~-~--~~~---~--~~
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: synonyms question
On Mon, Jul 7, 2008 at 10:24 PM, Michael Bayer [EMAIL PROTECTED] wrote:
On Jul 7, 2008, at 3:29 PM, Eric Lemoine wrote:
Hello
To override attribute behavior the 0.5 doc gives this example:
class MyAddress(object):
def _set_email(self, email):
self._email = email
def _get_email(self):
return self._email
email = property(_get_email, _set_email)
mapper(MyAddress, addresses_table, properties = {
'email':synonym('_email', map_column=True)
})
What won't work if I just set the python property and don't use the
synonym func:
mapper(MyAddress, addresses_table)
What difference does it make? I couldn't find an explanation in the
doc.
Sorry if that's a dumb question!
without synonym(), just add _email:addresses_table.c.email to your
mapper properties dict so that the email name is made available.
In that case, on DB read, SA will set _email directly and won't go
through _set_email(). Is that correct?
And with email:synonym('_email', map_column=True), will SA set
_email directly or will it go through _set_email()? My feeling is that
it will set it directly, so it is exactly the same as doing
_email:addresses_table.c.email.
And if one uses neither email:synonym('_email', map_column=True) nor
_email:addresses_table.c.email then SA will go through _set_email().
Is my understanding correct?
--
Eric
--~--~-~--~~~---~--~~
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: synonyms question
On Jul 7, 2008, at 5:46 PM, Eric Lemoine wrote:
without synonym(), just add _email:addresses_table.c.email to your
mapper properties dict so that the email name is made available.
In that case, on DB read, SA will set _email directly and won't go
through _set_email(). Is that correct?
yes.
And with email:synonym('_email', map_column=True), will SA set
_email directly or will it go through _set_email()? My feeling is that
it will set it directly, so it is exactly the same as doing
_email:addresses_table.c.email.
the mapper will always set _email directly. It never goes through
user-defined descriptors since it is essentially writing to
obj.__dict__ directly.
If you want Python code to take effect for data as it leaves the
database, you might look into creating a TypeDecorator with the
desired behavior.
--~--~-~--~~~---~--~~
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: synonyms question
On Mon, Jul 7, 2008 at 11:51 PM, Michael Bayer [EMAIL PROTECTED] wrote:
On Jul 7, 2008, at 5:46 PM, Eric Lemoine wrote:
without synonym(), just add _email:addresses_table.c.email to your
mapper properties dict so that the email name is made available.
In that case, on DB read, SA will set _email directly and won't go
through _set_email(). Is that correct?
yes.
And with email:synonym('_email', map_column=True), will SA set
_email directly or will it go through _set_email()? My feeling is that
it will set it directly, so it is exactly the same as doing
_email:addresses_table.c.email.
the mapper will always set _email directly. It never goes through
user-defined descriptors since it is essentially writing to
obj.__dict__ directly.
If you want Python code to take effect for data as it leaves the
database, you might look into creating a TypeDecorator with the
desired behavior.
That explains it all. Thanks Michael.
--
Eric
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
