Re: [sqlalchemy] cascade_backrefs=False broken for many-to-many relationships?
On Jun 23, 2011, at 7:12 PM, Robert Rollins wrote:
> I'm using SQLAlchemy 0.7.1 on a MySQL 5.1.57 database, and I'm getting
> unexpected behavior with the cascade_backrefs=False parameter for my
> many-to-many relationships.
>
>groups = relationship(ZKGroup, secondary=user_groups,
> backref='users', cascade_backrefs=False)
>
>def __init__(self, username, groups)
>self.username = username
>self.groups = groups
>
> Now, I would expect the cascade_backrefs=False option to prevent newly
> created ZKUser objects with a persistent ZKGroup object in their
> 'groups' list to not be added to the session. But the ZKUser object
> appears to being getting added to the session anyway. I can tell
> because this code:
>
>
> Is this a bug with cascade_backrefs=False? Or is it just not meant to
> be used with many-to-many relationships, or something like that?
I was pretty sure this came down to which side you put the flag on, keeping in
mind that *I* didn't know which side it should be on.Apparently its the
side that would be receiving cascades via a backref, not the one that would be
sending them:
groups = relationship(ZKGroup,
secondary=user_groups,
backref=backref('users', cascade_backrefs=False))
That is, the event is initiated by "self.groups", which then hits group.users
on the backref, but then the new User is not cascaded due to the flag.
The docstring for relationship() is accurate here, from the perspective that
the "cascade_backrefs" goes on the side that would be receiving the event, not
the one initiating it, but it only speaks in terms of one-to-many/many-to-one,
so even with all that typing I did it's still not clear. But with backref
events, it doesn't really matter what type of pattern is on each side.
The documentation for the flag in the "Session / Cascades" section, well
looking there it looks like the mappings are nonsensical, geezfixing that
now.
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sqlalchemy?hl=en.
>
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] cascade_backrefs=False broken for many-to-many relationships?
I'm using SQLAlchemy 0.7.1 on a MySQL 5.1.57 database, and I'm getting
unexpected behavior with the cascade_backrefs=False parameter for my
many-to-many relationships.
Here's the pertinent table code:
Base = declarative_base()
class ZKGroup(Base):
__tablename__ = 'groups'
id = Column(Integer, primary_key=True)
name= Column(String(512))
def __init__(self, name)
self.name = name
user_groups = Table('user_groups', Base.metadata,
Column('user_id', String(128), ForeignKey('users.username')),
Column('group_id', Integer, ForeignKey('groups.id'))
)
class ZKUser(Base):
__tablename__ = 'users'
username = Column(String(128), primary_key=True)
groups = relationship(ZKGroup, secondary=user_groups,
backref='users', cascade_backrefs=False)
def __init__(self, username, groups)
self.username = username
self.groups = groups
Now, I would expect the cascade_backrefs=False option to prevent newly
created ZKUser objects with a persistent ZKGroup object in their
'groups' list to not be added to the session. But the ZKUser object
appears to being getting added to the session anyway. I can tell
because this code:
group = ZKGroup('group1')
session.add(group)
user = ZKUser('user1')
session.add(user)
self.session.commit()
user2 = ZKUser('user1', [group])
session.merge(user2)
session.commit()
Throws this exception from the session.merge() call:
Traceback (most recent call last):
File "TestScript.py", line 7
session.merge(user2)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
lib/python2.6/site-packages/sqlalchemy/orm/session.py", line 1220, in
merge
self._autoflush()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
lib/python2.6/site-packages/sqlalchemy/orm/session.py", line 901, in
_autoflush
self.flush()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
lib/python2.6/site-packages/sqlalchemy/orm/session.py", line 1473, in
flush
self._flush(objects)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
lib/python2.6/site-packages/sqlalchemy/orm/session.py", line 1542, in
_flush
flush_context.execute()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
lib/python2.6/site-packages/sqlalchemy/orm/unitofwork.py", line 327,
in execute
rec.execute(self)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
lib/python2.6/site-packages/sqlalchemy/orm/unitofwork.py", line 471,
in execute
uow
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
lib/python2.6/site-packages/sqlalchemy/orm/mapper.py", line 1902, in
_save_obj
state_str(existing)))
FlushError: New instance with identity key
(, ('user1',)) conflicts
with persistent instance
However, if I add a call to 'session.expunge(user2)' right before
'session.merge(user2)', the merge completes and user1 gets associated
to group1 in the DB, as expected.
Is this a bug with cascade_backrefs=False? Or is it just not meant to
be used with many-to-many relationships, or something like that?
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Re: session.execute w/ list of values instead of dict?
If you are using Session.connection() with the ORM, it gives you a connection that's part of the Session's transaction. If you aren't working with the ORM and just have an Engine, you need to get a Connection then call begin() on it. this stuff is all up there if you poke around a bit. On Jun 23, 2011, at 5:54 PM, Wells Oliver wrote: > Hmm, new to SQLAlchemy here, but if I want transactions, then I need > to go the Session route, correct? > > On Jun 23, 2:48 pm, Michael Bayer wrote: >> On Jun 23, 2011, at 5:08 PM, Wells Oliver wrote: >> >>> W/ psycopg2, you can do a cursor.execute(query, list) where list is an >>> actual python list of values : [1,2,3] >> >>> W/ SQLAlchemy, it seems the session.execute(query, values) will only >>> accept a dictionary for values. Am I missing something? Can I pass a >>> list instead? Thanks. >> >> I was a little surprised the docs don't refer to the fact that you should >> use connection() for this case, so I updated them: >> >> http://www.sqlalchemy.org/docs/orm/session.html#sqlalchemy.orm.sessio...http://www.sqlalchemy.org/docs/core/connections.html#sqlalchemy.engin... >> >> "If a plain string is passed, it is first converted to a text() construct, >> which here means that bind parameters should be specified using the format >> :param. If raw DBAPI statement execution is desired, use >> Session.connection() to acquire a Connection, then call its execute() >> 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 > sqlalchemy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. > -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Re: session.execute w/ list of values instead of dict?
Hmm, new to SQLAlchemy here, but if I want transactions, then I need to go the Session route, correct? On Jun 23, 2:48 pm, Michael Bayer wrote: > On Jun 23, 2011, at 5:08 PM, Wells Oliver wrote: > > > W/ psycopg2, you can do a cursor.execute(query, list) where list is an > > actual python list of values : [1,2,3] > > > W/ SQLAlchemy, it seems the session.execute(query, values) will only > > accept a dictionary for values. Am I missing something? Can I pass a > > list instead? Thanks. > > I was a little surprised the docs don't refer to the fact that you should use > connection() for this case, so I updated them: > > http://www.sqlalchemy.org/docs/orm/session.html#sqlalchemy.orm.sessio...http://www.sqlalchemy.org/docs/core/connections.html#sqlalchemy.engin... > > "If a plain string is passed, it is first converted to a text() construct, > which here means that bind parameters should be specified using the format > :param. If raw DBAPI statement execution is desired, use Session.connection() > to acquire a Connection, then call its execute() 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] session.execute w/ list of values instead of dict?
On Jun 23, 2011, at 5:08 PM, Wells Oliver wrote: > W/ psycopg2, you can do a cursor.execute(query, list) where list is an > actual python list of values : [1,2,3] > > W/ SQLAlchemy, it seems the session.execute(query, values) will only > accept a dictionary for values. Am I missing something? Can I pass a > list instead? Thanks. > I was a little surprised the docs don't refer to the fact that you should use connection() for this case, so I updated them: http://www.sqlalchemy.org/docs/orm/session.html#sqlalchemy.orm.session.Session.execute http://www.sqlalchemy.org/docs/core/connections.html#sqlalchemy.engine.base.Connection.execute "If a plain string is passed, it is first converted to a text() construct, which here means that bind parameters should be specified using the format :param. If raw DBAPI statement execution is desired, use Session.connection() to acquire a Connection, then call its execute() 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] session.execute w/ list of values instead of dict?
W/ psycopg2, you can do a cursor.execute(query, list) where list is an actual python list of values : [1,2,3] W/ SQLAlchemy, it seems the session.execute(query, values) will only accept a dictionary for values. Am I missing something? Can I pass a list instead? 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] alternative driver for firebird
On Jun 23, 2011, at 7:10 AM, bigt wrote: > in addition to the currently supported kinterbasdb, there is an > alternative python interface, which is relatavely new, but has the > advantage of already supporting Python3, and which is likely to become > the preferred interface when Firebird3 is released.. > > See http://pypi.python.org/pypi/firebirdsql/ > > > I should like to request that sqlalchemy implement support for this > alternative interface, in the same ways as there are multiple drivers > for postgresql. This is an accepted feature request and just needs a little bit of volunteerism to get it started.It's ticket 2125: http://www.sqlalchemy.org/trac/ticket/2125 Per-DBAPI dialects like these are very easy to add and we get help from the community on them regularly, the work is just to get the file and its structures in place, get a successful SQL round trip going, and get some of the rudimentary tests to run. I'm adding to the ticket now: A new file called lib/sqlalchemy/dialects/firebird/firebirdsql.py, which would contain code very similar to that of lib/sqlalchemy/dialects/firebird/kinterbasdb.py. Then the "hello world" test for a dialect is that it gets through at least most of "test.sql.test_query" and in this case "test.dialect.test_firebird". Once there's some code in place I'm happy to help whoever is involved to debug basic issues. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Deferred loader for attribute for Table having large number of columns.
Hello, Sorry for the late response. Issue got solved, it is not problem with SA. mx.ODBC,unixODBC driver has limitation over column names length to support ANSI standards (i.e 38-1). I renamed my table column names and issue got solved. Thanks, On Mon, Jun 13, 2011 at 8:07 PM, Michael Bayer wrote: > > On Jun 13, 2011, at 10:28 AM, pavi ena wrote: > > > Hello, > > > > I am using SQLAlchemy-0.7.1 and i am facing "Deferred loader for > attribute" Error while trying to access the table columns in my code. > > > > I have table with huge number of columns around 200 fields and i have > defined the schema and entity with hybrid declarative_base approach as > below. > > I have some sample testcases to assert newly inserted values in db with > normal python assert statements. When i run my sample test cases i am > getting > > following error: > > > >KeyError: "Deferred loader for attribute 'is_updated' failed to > populate correctly" > > > > Below is my code example due to large number of columns i have not > defined entire db Table definition here. > > > > Please suggest to me fix this error. > > would need a reproducing test case, it suggests something to do with the > mechanics of the table but its not clear nor is it an issue seen before. > > > > > Just a thought is this error is raised for following reasons. > > > > 1. If table column name length is more than 30 chars. > > "is_updated" doesn't appear to be more than 30 characters to me. Did you > create a test that sees if this is the case ? > > > 2. If table has large number of columns defined. > > Did you create a test with a fewer number of columns in a table to see if > this is the case ? > > > -- > 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+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. > > -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] alternative driver for firebird
in addition to the currently supported kinterbasdb, there is an alternative python interface, which is relatavely new, but has the advantage of already supporting Python3, and which is likely to become the preferred interface when Firebird3 is released.. See http://pypi.python.org/pypi/firebirdsql/ I should like to request that sqlalchemy implement support for this alternative interface, in the same ways as there are multiple drivers for postgresql. Regards -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
