Hi Michael et al,
basic question: Can I call identity_key in after_commit? If not, are there any
alternatives?
Explanation:
For our GUI application I tried to extend SQLAlchemy to signal database
updates. The following constraints apply:
* Updates are done in background threads and
On Thu, 2011-05-26 at 08:34 +0200, Torsten Landschoff wrote:
basic question: Can I call identity_key in after_commit? If not, are there
any alternatives?
A bit of extra information: My usage of identity_key stems from this
thread on this list:
Hi all,
I've run into an issue when mapping a deferred column_property that uses a
custom SQL construct. I get a KeyError: 'default' because there is no
compile function for the default dialect, but it seems to me that the
default dialect should never be used.
Here's an extended stack trace
On May 25, 2011, at 10:52 PM, Nathan Wright wrote:
Hi all,
I've run into an issue when mapping a deferred column_property that uses a
custom SQL construct. I get a KeyError: 'default' because there is no compile
function for the default dialect, but it seems to me that the default
On May 26, 2011, at 2:34 AM, Torsten Landschoff wrote:
Hi Michael et al,
basic question: Can I call identity_key in after_commit? If not, are there
any alternatives?
absolutely. identity_key is strictly informational with regards to the state
present on the target object.
To move the
Hi,
Just a easy question, why we don't have a contains_eager_all like we do with
joinedload?
By the way, I don't exactly understand why we shouldn't use the _all version
always.
Example (from
http://www.sqlalchemy.org/docs/orm/loading.html?highlight=contains_eager#contains-eager
):
Hi,
I got this habit of looking at which queries currently are live on
mysql db (via innotop).
And I like to add query name to each query.. example:
SELECT /* custom comment here...users living in Poland */ id FROM
users WHERE country = 'pl';
This way I can quickly identify queries that
On May 26, 2011, at 11:02 AM, Israel Ben Guilherme Fonseca wrote:
Hi,
Just a easy question, why we don't have a contains_eager_all like we do with
joinedload?
contains_eager() should always act in an all context since there's little use
otherwise. This was fixed in 0.7 and is ticket
Hmm, nice, I'm still with the 0.6.7, so that's why I missed it.
Thanks again for the superfast-effective answer.
2011/5/26 Michael Bayer mike...@zzzcomputing.com
On May 26, 2011, at 11:02 AM, Israel Ben Guilherme Fonseca wrote:
Hi,
Just a easy question, why we don't have a
Hello,
I work on making sqlalchemy-migrate [1] work with SQLAlchemy 0.7. I
fixed all broken unit tests except for one related to adding a new
column with a foreign key to an existing table. We have a continues
integration system (Jenkins CI) at [2] that provides the output of the
failing test.
On May 26, 2011, at 11:58 AM, Torsten Landschoff wrote:
How much more context would be helpful? Basically, this is the top of
the backtrace. Above of that call is only the event handler hierarchy.
File /home/torsten/workspace/loco2-git/loco2/ui/wizard/importwizard.py,
line 69, in
Hi,
I'm trying to construct a query that have a subquery, and that subquery
references the outer query attribute. It's almost working actually:
Intended select:
select * from curso c join matricula m on c.id_curso = m.id_curso
where m.id_aluno = 1
On May 26, 2011, at 11:41 AM, Jan Dittberner wrote:
Hello,
I work on making sqlalchemy-migrate [1] work with SQLAlchemy 0.7. I
fixed all broken unit tests except for one related to adding a new
column with a foreign key to an existing table. We have a continues
integration system (Jenkins
This seems to be an issue of poor documentation on our part. Here are new
documentation elements, linked from the ORM tutorial which was previously the
only place contains() was mentioned, fully describing the behavior of
contains(), and how any() and outerjoin() are more appropriate if OR
I did a bit more of digging in the docs and found the 'select_from' method.
I thought that it would force the FROM statement to use ONLY what I pass as
argument. But it didn't.
session.query(func.max(alias.data)).select_from(alias).filter(alias.id_curso
== Matricula.id_curso).subquery()
It
2011/5/26 Michael Bayer mike...@zzzcomputing.com:
On May 26, 2011, at 11:41 AM, Jan Dittberner wrote:
Hello,
I work on making sqlalchemy-migrate [1] work with SQLAlchemy 0.7. I
fixed all broken unit tests except for one related to adding a new
column with a foreign key to an existing
On May 26, 2011, at 4:04 PM, Jan Dittberner wrote:
the table.append_column() call was the missing piece of information.
In SQLA 0.6 it was not needed, in SQLA 0.7 it seems to be required.
the Column is guaranteed not at all associated with a Table if you didn't call
table.append_column(col).
I saw that, but I'm not using a subquery in the from clause. Maybe I wasn't
clear enough. Example:
outeruser = aliased(User)
inneruser = aliased(User)
innerselect = session.query(inneruser.id).filter(inneruser.id ==
outeruser.id).subquery()
At this point I already have a problem, the generated
On May 26, 2011, at 5:03 PM, Israel Ben Guilherme Fonseca wrote:
I saw that, but I'm not using a subquery in the from clause. Maybe I wasn't
clear enough. Example:
outeruser = aliased(User)
inneruser = aliased(User)
innerselect = session.query(inneruser.id).filter(inneruser.id ==
Sweet, it's working. :)
Now let's wait for the 0.8.
2011/5/26 Michael Bayer mike...@zzzcomputing.com
On May 26, 2011, at 5:03 PM, Israel Ben Guilherme Fonseca wrote:
I saw that, but I'm not using a subquery in the from clause. Maybe I wasn't
clear enough. Example:
outeruser =
Thank you!
As I'm sure some of the people in the list already know, I also asked
this same question in StackOverflow, and I got a couple of interesting
answers.
Just in case:
http://stackoverflow.com/questions/6118783/sqlalchemy-check-if-one-object-is-in-any-relationship-or-object-relationship1
21 matches
Mail list logo
