Re: [sqlalchemy] Windowed Queries breaking after a commit and emitting many, many Selects.
Using a scoped session with a session generator and I didn't want expire_on_commit to be False for everything, so setting it using the Session constructor wouldn't work properly. If a session was created prior to the one that needed that flag, it'd give me a ProtocolError since it couldn't change the session after it'd already been created. Manually setting the expire_on_commit attribute in the session and setting it back after it was done worked fine, though, and didn't mess with the scoped session pool: with db_session() as db: db.expire_on_commit = False # do stuff db.expire_on_commit = True -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
[sqlalchemy] Obtaining the SQL query for a lazy load programmatically
I observe that the query for a lazy load is generated here: https://bitbucket.org/zzzeek/sqlalchemy/src/e1d1d999c9a688f4c8dbbe885438c63d6ef494c6/lib/sqlalchemy/orm/strategies.py?at=master#cl-551 I would like to run queries through an EXPLAIN QUERY PLAN or an ANALYZE programmatically for many properties. Is there an easy way to achieve that? It looks not since it doesn't like the query is exposed. The only way I'm aware of to get it is to cause a lazy load and have logging enabled (or add an event handler which observes the executed statement), but I'd like to know if there is a way to avoid doing that. Thanks, - Peter -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
[sqlalchemy] Status of column comment support (mainly interested in MySQL)
Hey list, What's the state of support for column comments? I was only able to dig out one mention of this — from 2009 [1] — and the docs only seem to mention this in the description of the `Column.doc` attribute. [2] I'd be interested in helping out with this one, if possible. Just let me know what's the story so far. [1] https://bitbucket.org/zzzeek/sqlalchemy/issue/1546 [2] http://docs.sqlalchemy.org/en/latest/core/metadata.html#sqlalchemy.schema.Column.params.doc -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
[sqlalchemy] expressing an inferred relationship
I've been staring at this a few hours, and can't figure out how to adapt a
join/query into a relationship. The archives and docs don't seem to help
much.
It seems reminiscent to an earlier question by Simon King (
https://groups.google.com/d/topic/sqlalchemy/OtI4Z8v7gRs/discussion ) and
some of the more advanced relationship docs -- but I fear I'm overthinking
this.
At the most basic form, I have two tables that can serve as
intermediary/association tables to the same tables:
class Foo(Base):
__tablename__ = 'foo'
id = Column(Integer, primary_key=True)
class Bar(Base):
__tablename__ = 'bar'
id = Column(Integer, primary_key=True)
class FooBarA(Base):
__tablename__ = 'foo_bar_a'
id = Column(Integer, primary_key=True)
foo_id = Column(Integer, ForeignKey(foo.id), nullable=False)
bar_id = Column(Integer, ForeignKey(bar.id), nullable= False)
class FooBarB(Base):
__tablename__ = 'foo_bar_b'
id = Column(Integer, primary_key=True)
foo_id = Column(Integer, ForeignKey(foo.id), nullable=False)
bar_id = Column(Integer, ForeignKey(bar.id), nullable= False)
i am trying to make the collection of similar relationships available to
each association class
I was hoping something simple would work:
FooBarA.foo_bar_bs = relationship(FooBarB,
primaryjoin=and_(FooBarA.foo_id==FooBarB.foo_id,
FooBarA.bar_id==FooBarB.bar_id))
FooBarB.foo_bar_as = relationship(FooBarA,
primaryjoin=and_(FooBarA.foo_id==FooBarB.foo_id,
FooBarA.bar_id==FooBarB.bar_id))
session.query(FooBarB).options(joinedload('foo_bar_a'))
session.query(FooBarB).options(subqueryload('foo_bar_a'))
But SqlAlchemy wants me to stick to the pattern where primary keys are
involved. I totally understand - that stuff is needed for all the
advanced collections operations.
It looks like I could achieve what I want with some of the examples in the
advanced relationships docs, but it looks like it wouldn't be as
performance friendly as direct queries, since I'd have to map everything
onto the original underlying primary keys.
Does anyone know of a more low-impact approach to handling this sort of orm
relationship? I think I might just use a @property on the class
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
