Re: [sqlalchemy] full outer join?
I've added a PR for full=True in outerjoin(), join() and Join(): https://github.com/zzzeek/sqlalchemy/pull/167 FULL OUTER JOIN, besides other uses, is very useful in ETLs for doing transformations on top of table differences. Using two outer joins, as suggested in one of the above posts, unnecessarily overcomplicates statements. Stefan On Monday, December 2, 2013 at 8:09:14 PM UTC-5, Michael Bayer wrote: if someone wants to pullreq the kw argument “full=True” on .outerjoin(), if it’s done effectively I won’t reject it. On Dec 2, 2013, at 5:43 PM, Jonathan Vanasco jona...@findmeon.com javascript: wrote: On Monday, December 2, 2013 2:46:20 PM UTC-5, Michael Bayer wrote: well the alternative to full outer join is a union of two outer joins - more tedious.“full outer join” isn’t in the library but you can just subclass Join and do a @compiles to get that exact syntax. you could also query the union of two outer joins, by treating it as a nested subquery. that is not only tedious, but painful and annoying. you could do it though! -- 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. 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/d/optout.
[sqlalchemy] The use of SQLAlchemy for a long term project
Hi, I'm investigating the use and dependency on SQLAlchemy for a long-term astronomy project. Given Version 1.0 just came out, I've got a few questions about it. 1. It seems SQLAlchemy generally EOLs versions after about two releases/years. Is this an official policy? Is this to continue with version 1.0 as well? Or is it possible 1.0 might be a something of a long-term release. 2. While well documented and typically minimal, SQLAlchemy does have occasional API and behavioral changes to be aware of between versions. Is the 1.0 API more likely to be stable on the time frame of ~4 years? Put another way, would you expect that it should be easier to migrate from version 1.0 to the 1.4 (or whatever the current version is) of SQLAlchemy in five years than it would be to migrate from 0.6 to 1.0 today. I know these questions are often hard to answer with any certainty, but these sorts of projects typically outlive the software they are built on and are often underfunded as far as software maintenance goes, so we try to plan accordingly. (Of course, some people just give up and through everything in VMs behind firewalls) Brian -- 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] when do I have to do a rollback so the app keep working fine
Hi everyone, I have a considerably amount of code that uses SQLAlchemy and I want to implement a decorator that captures the SQLAlchemy exceptions, then make session.rollback() and recall the decorated function, so I don't have to write the try except statement whenever I use SQLAlchemy. For implementing such a decorator I need the exceptions I can certainly capture to make session.rollback() and the app keep working fine because there are exceptions that will cause an endless loop and should never be captured (e.g., generating the same primary key due to a bug and always raising IntegrityError) So, can anyone tell me what are those exceptions that are safe to make session.rollback()? -- 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.
Re: [sqlalchemy] Reverse delete orphan?
On Tuesday, April 7, 2015 at 4:00:28 PM UTC-7, Michael Bayer wrote: One event approach would be the before_flush() event, you search through session.deleted for all Container objects; within Container, locate all Tag entries with that Container as the ultimate parent and mark them all as deleted as well. With the before_flush() approach, you can use the Session and your objects in the usual way. Thanks Michael, that was very helpful. We ended up going with your first approach and it seems to be working out for us. I really appreciate the detailed response. I'm new to SQL Alchemy, coming to it from a Java/Hibernate background and I've been very impressed with the framework and the accompanying documentation. -- 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.
