Re: [sqlalchemy] multiple databases?
thanks! in fact i'm using twisted, and i make use of some abstractions on top of query so they can be treated as a deferred :) but either way, i'm using a very modified version of this: http://techspot.zzzeek.org/2012/01/11/django-style-database-routers-in-sqlalchemy/ it's been working good so far (or better, since yesterday), with multiple connections to a postgres database and also to sqlite :) my best regards, richard. On 12/11/2013 03:48 AM, Jameson Lee wrote: If you are using Flask, check out binds[1] with Flask-SQLAlchemy. [1] http://pythonhosted.org/Flask-SQLAlchemy/binds.html On Monday, December 9, 2013 12:33:46 PM UTC-8, warwickp wrote: Hi Richard There are no problems connecting to multiple database sources in the one application - we do it all the time :-) Cheers Warwick On 10 Dec 2013, at 4:08 am, Richard Gerd Kuesters ric...@humantech.com.br javascript: wrote: hi all, i don't know if anyone have to go through this, but here's a question: is it possible to use multiple databases sources (like postgres and mysql) in a single application? my best regards, richard. -- 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+...@googlegroups.com javascript:. To post to this group, send email to sqlal...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/sqlalchemy http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/groups/opt_out https://groups.google.com/groups/opt_out. -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [sqlalchemy] Find out what's going to be deleted
Hi, On Sunday, June 2, 2013 5:47:03 PM UTC+1, pub...@enkore.de wrote: Thanks a lot for your comprehensive answer! I was able to solve my problem by implementing your first suggestion. Orphans do not play a role yet� I think :-) On 06/02/2013 05:09 PM, Michael Bayer wrote: The only deletes that aren't present in session.deleted before the flush are those that will occur because a particular object is an orphan, and the objects which would be deleted as a result of a cascade on that orphan. So without orphans taken into account, session.deleted tells you everything that is to be deleted. To take orphans into account requires traversing through all the relationships as the unit of work does, looking for objects that are currently orphans (there's an API function that will tell you this - if the object is considered an orphan by any attribute that refers to it with delete-orphan cascade, it's considered an orphan), and then traversing through the relationships of those orphans, considering them to be marked as deleted, and then doing all the rules again for those newly-deleted objects. The system right now is implemented by orm/dependency.py. It is probably not hard to literally run a unit of work process across the session normally, but just not emit the SQL, this would give you the final flush plan. But this is an expensive process that I wouldn't want to be calling all the time. A feature add is difficult here because the use case is not clear. Knowing what will be deleted basically requires half the flush process actually proceed. But you can already implement events inside the flush process itself, most directly the before_delete() and after_delete() events that will guaranteed catch everything.So the rationale for a new feature that basically runs half the flush, before you just do the flush anyway and could just put events inside of it, isn't clear. The before_delete and after_delete shouldn't make use of the current Session though, according to http://docs.sqlalchemy.org/en/rel_0_9/orm/events.html?highlight=after_delete#sqlalchemy.orm.events.MapperEvents.after_delete Book keeping within the one transaction becomes somewhat difficult when those are the only places to catch deletes caused by becoming an orphan. Any suggestions on how one might go about adding book keeping rows with this information to the Session? i.e. Like in the after_delete so that it picks up orphan deletes? On Jun 2, 2013, at 9:46 AM, pub...@enkore.de javascript: wrote: When using more complex, hierarchical models with differing settings on how cascade deletes are handled it gets quite hard to figure out beforehand what a delete() will exactly do with the database. I couldn't find any way to get this piece of information (Hey SQLAlchemy, what will be deleted if I delete that object over there?) from SQLAlchemy. Implementing this by myself doesn't really seem like an option since this would result sooner or later in situations where my prediction and the actual consequences of the delete() differ, which would be very� unpleasant for the user. (This question was also posted on SO: http://stackoverflow.com/q/16875605/675646 ) Cheers, Tim -- 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/groups/opt_out.
[sqlalchemy] subqueryload does not populate relation if backref is joined
My question from stackoverflow:
http://stackoverflow.com/questions/20519910/subqueryload-does-not-populate-relation-if-backref-is-joined
Why CASE 4 (see output) does not provide related children. It looks like if
it happens because subqueryload does not populate relation if backref is
joinedload. But what logic is behind this? Is it a bug?
Please, note diffence between these lines:
children1 = relationship('Child1', back_populates='parent',
cascade='all', lazy='noload')
children2 = relationship('Child2', back_populates='parent',
cascade='all', lazy='noload')
parent = relationship('Parent', back_populates='children1',
cascade='all', lazy='joined')
parent = relationship('Parent', back_populates='children2',
cascade='all', lazy='subquery')
parent =
session3.query(Parent).options([joinedload('children1')]).get(1)
parent =
session4.query(Parent).options([joinedload('children2')]).get(1)
parent =
session5.query(Parent).options([subqueryload('children1')]).get(1)
parent =
session6.query(Parent).options([subqueryload('children2')]).get(1)
CODE -
from sqlalchemy import Column, Integer, String, ForeignKey
from sqlalchemy import create_engine
from sqlalchemy.orm import relationship, sessionmaker, subqueryload,
joinedload
from sqlalchemy.ext.declarative import declarative_base
Base = declarative_base()
class Parent(Base):
__tablename__ = 'parent'
id = Column(Integer, primary_key=True)
name = Column(String(20))
children1 = relationship('Child1', back_populates='parent',
cascade='all', lazy='noload')
children2 = relationship('Child2', back_populates='parent',
cascade='all', lazy='noload')
class Child1(Base):
__tablename__ = 'child1'
id = Column(Integer, primary_key=True)
name = Column(String(20))
parent_id = Column(Integer, ForeignKey('parent.id',
ondelete='CASCADE'))
parent = relationship('Parent', back_populates='children1',
cascade='all', lazy='joined')
def __repr__(self):
return repr((self.id, self.name, self.parent_id))
class Child2(Base):
__tablename__ = 'child2'
id = Column(Integer, primary_key=True)
name = Column(String(20))
parent_id = Column(Integer, ForeignKey('parent.id',
ondelete='CASCADE'))
parent = relationship('Parent', back_populates='children2',
cascade='all', lazy='subquery')
def __repr__(self):
return repr((self.id, self.name, self.parent_id))
engine = create_engine('sqlite:///:memory:')
Base.metadata.create_all(engine)
Session = sessionmaker(bind=engine)
session1 = Session()
session1.add(Parent(id=1, name='parent'))
session1.add(Child1(id=1, name='child1_1', parent_id=1))
session1.add(Child1(id=2, name='child1_2', parent_id=1))
session1.add(Child2(id=1, name='child2_1', parent_id=1))
session1.add(Child2(id=2, name='child2_2', parent_id=1))
session1.commit()
session1.expunge_all()
session1.close()
session2 = Session()
parent = session2.query(Parent).get(1)
print 'CASE 1 (no options):', parent.id, parent.children1,
parent.children2
session2.close()
session3 = Session()
parent =
session3.query(Parent).options([joinedload('children1')]).get(1)
print 'CASE 2 (joined vs joinedload):', parent.id, parent.children1
session3.close()
session4 = Session()
parent =
session4.query(Parent).options([joinedload('children2')]).get(1)
print 'CASE 3 (subquery vs joinedload):', parent.id, parent.children2
session4.close()
session5 = Session()
parent =
session5.query(Parent).options([subqueryload('children1')]).get(1)
print 'CASE 4 (joined vs subqueryload):', parent.id, parent.children1
session5.close()
session6 = Session()
parent =
session6.query(Parent).options([subqueryload('children2')]).get(1)
print 'CASE 5 (subquery vs subqueryload):', parent.id, parent.children2
session6.close()
Output
CASE 1 (no options): 1 [] []
CASE 2 (joined vs joinedload): 1 [(1, u'child1_1', 1), (2, u'child1_2',
1)]
CASE 3 (subquery vs joinedload): 1 [(1, u'child2_1', 1), (2,
u'child2_2', 1)]
CASE 4 (joined vs subqueryload): 1 []
CASE 5 (subquery vs subqueryload): 1 [(1, u'child2_1', 1), (2,
u'child2_2', 1)]
--
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/groups/opt_out.
[sqlalchemy] sqlacodegen 1.1.3 released.
This release fixes compatibility with SQLAlchemy 0.8.3 and onwards. The test suite passes on SQLAlchemy 0.9.0b1 as well. -- 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/groups/opt_out.
Re: [sqlalchemy] Find out what's going to be deleted
On Dec 11, 2013, at 8:02 AM, Tim Kersten t...@io41.com wrote: The before_delete and after_delete shouldn't make use of the current Session though, according to http://docs.sqlalchemy.org/en/rel_0_9/orm/events.html?highlight=after_delete#sqlalchemy.orm.events.MapperEvents.after_delete Book keeping within the one transaction becomes somewhat difficult when those are the only places to catch deletes caused by becoming an orphan. Any suggestions on how one might go about adding book keeping rows with this information to the Session? i.e. Like in the after_delete so that it picks up orphan deletes? you can make use of the Session within the mapper-level events, you just can’t rely upon any actual changes you make to that Session actually being acted upon within the flush, as the flush plan has already been determined at that point. In fact logic was added in recent months that will cause the Session to flush again if events have dirtied up the session within the flush, so these warnings are already becoming too strong for what the current reality is - I would like to dial them back a bit, although this would require nailing down exactly what cases still won’t work as expected. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [sqlalchemy] multiple databases?
richard - how are you handle the scoping and management of sessions ? i'm wanting (badly) to convert some twisted code that is using raw sql through their db api onto the sqlalchemy model for my core app. -- 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/groups/opt_out.
Re: [sqlalchemy] Find out what's going to be deleted
On 11 Dec 2013, at 16:32, Michael Bayer mike...@zzzcomputing.com wrote: On Dec 11, 2013, at 8:02 AM, Tim Kersten t...@io41.com wrote: The before_delete and after_delete shouldn't make use of the current Session though, according to http://docs.sqlalchemy.org/en/rel_0_9/orm/events.html?highlight=after_delete#sqlalchemy.orm.events.MapperEvents.after_delete Book keeping within the one transaction becomes somewhat difficult when those are the only places to catch deletes caused by becoming an orphan. Any suggestions on how one might go about adding book keeping rows with this information to the Session? i.e. Like in the after_delete so that it picks up orphan deletes? you can make use of the Session within the mapper-level events, you just can’t rely upon any actual changes you make to that Session actually being acted upon within the flush, as the flush plan has already been determined at that point.In fact logic was added in recent months that will cause the Session to flush again if events have dirtied up the session within the flush, so these warnings are already becoming too strong for what the current reality is - I would like to dial them back a bit, although this would require nailing down exactly what cases still won’t work as expected. Excellent, thanks. -- 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/groups/opt_out.
Re: [sqlalchemy] multiple databases?
quite frankly, i'm handling them using deferreds, in a similar way you can find in sqlalchemy-future: https://github.com/lunant/SQLAlchemy-Future with this -- and using scoped sessions based on the callbacks, i can close the session quite nice. the code is very, very ugly for now, but i plan to share it somewhere in the near future :) i did use some ideas behind txpostgres impl, too. best regards, richard. On 12/11/2013 02:52 PM, Jonathan Vanasco wrote: richard - how are you handle the scoping and management of sessions ? i'm wanting (badly) to convert some twisted code that is using raw sql through their db api onto the sqlalchemy model for my core app. -- 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/groups/opt_out.
Re: [sqlalchemy] table inheritance: how to change a record from base type to derived type?
On Tue, Dec 10, 2013 at 3:54 PM, Michael Bayer mike...@zzzcomputing.comwrote: On Dec 10, 2013, at 5:04 PM, Iain Duncan iainduncanli...@gmail.com wrote: Hi, I'm stuck on how to do something that I'm sure must be possible. I have two kinds of records, using table inheritance, Client, and SpecialClient. SpecialClient has extra fields and it's own polymorphic identity. I need to *promote* a and existing client record to a special client. I tried just making a SpecialClient and copying over attributes, but this is giving me can't set attribute error messages. Can anyone tell me what the *right* way to do change a polymorphic type, while keeping it's ID the same, would be? In my case, the ID in the derived type is an fkey to the base type table's id col. if its joined inheritance, you have to INSERT into the new table manually, that feature isn’t supported right now. if it’s single, try emitting an UPDATE for the “discriminator” column, then reloading the object. I think it's joined inheritance? The derived table's primarky key is an id column that is also an fkey to the base table's id column and the base table has a _type column holding the poly id. Does this mean I should drop into sql directly to create the record in the derived table and it will just work? thanks Michael! iain Thanks! Iain -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [sqlalchemy] table inheritance: how to change a record from base type to derived type?
On Dec 11, 2013, at 12:45 PM, Iain Duncan iainduncanli...@gmail.com wrote: On Tue, Dec 10, 2013 at 3:54 PM, Michael Bayer mike...@zzzcomputing.com wrote: On Dec 10, 2013, at 5:04 PM, Iain Duncan iainduncanli...@gmail.com wrote: Hi, I'm stuck on how to do something that I'm sure must be possible. I have two kinds of records, using table inheritance, Client, and SpecialClient. SpecialClient has extra fields and it's own polymorphic identity. I need to *promote* a and existing client record to a special client. I tried just making a SpecialClient and copying over attributes, but this is giving me can't set attribute error messages. Can anyone tell me what the *right* way to do change a polymorphic type, while keeping it's ID the same, would be? In my case, the ID in the derived type is an fkey to the base type table's id col. if its joined inheritance, you have to INSERT into the new table manually, that feature isn’t supported right now. if it’s single, try emitting an UPDATE for the “discriminator” column, then reloading the object. I think it's joined inheritance? The derived table's primarky key is an id column that is also an fkey to the base table's id column and the base table has a _type column holding the poly id. Does this mean I should drop into sql directly to create the record in the derived table and it will just work”? you need to manipulate the tables directly, and then totally reload the original object fresh. pretty much make the ORM think the previous Client never existed. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [sqlalchemy] subqueryload does not populate relation if backref is joined
On Dec 11, 2013, at 8:12 AM, Dmitry Mugtasimov dmugtasi...@gmail.com wrote: My question from stackoverflow: http://stackoverflow.com/questions/20519910/subqueryload-does-not-populate-relation-if-backref-is-joined Why CASE 4 (see output) does not provide related children. It looks like if it happens because subqueryload does not populate relation if backref is joinedload. But what logic is behind this? Is it a bug? it is a bug, involving specific details of when each query invokes and what the state of the objects are when it encounters them.I’ve done all the heavy thinking for it at http://www.sqlalchemy.org/trac/ticket/2887, just need to refine the solution and write some tests, it will be for 0.8. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [sqlalchemy] subqueryload does not populate relation if backref is joined
Thank you very much. среда, 11 декабря 2013 г., 21:58:57 UTC+4 пользователь Michael Bayer написал: On Dec 11, 2013, at 8:12 AM, Dmitry Mugtasimov dmugt...@gmail.comjavascript: wrote: My question from stackoverflow: http://stackoverflow.com/questions/20519910/subqueryload-does-not-populate-relation-if-backref-is-joined Why CASE 4 (see output) does not provide related children. It looks like if it happens because subqueryload does not populate relation if backref is joinedload. But what logic is behind this? Is it a bug? it is a bug, involving specific details of when each query invokes and what the state of the objects are when it encounters them.I've done all the heavy thinking for it at http://www.sqlalchemy.org/trac/ticket/2887, just need to refine the solution and write some tests, it will be for 0.8. -- 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/groups/opt_out.
