> > >> > However, when the fetch query actually runs, it includes the non aliased >> > table name as well as the aliased table name in the from statement: >> > >> > select t.idfrom *some_table, some_table as t* where t.some_column = >> > /someValue/ >> >> well that's not a DELETE statement. query.delete() emits a DELETE >> statement and you'd have to look in the SQL logs to see it. >> >> There's no "bug" here as DELETE does not support deleting directly from >> an alias of a table; it's likely emitting DELETE .. FROM and assuming >> you want to do some kind of join against the aliased form of your table. >> >> Otherwise what SQL are you looking for this to produce that has DELETE >> but also an aliased form of the table? > > > > I know that isn't the delete statement. It is the FETCH statement before the delete is called. http://docs.sqlalchemy.org/en/latest/orm/query.html#sqlalchemy.orm.query.Query.delete
I have taken to the habit of using "aliased" for many of my sqlalchemy queries because it makes it much easier for me to read the query on the database when I have to troubleshoot an issue. Most queries are not as simple as the example I posted. Aliased tables do not work with query.delete(), at least with *synchronize_session='fetch'*. I can live with that. I was just surprised by it and thought I'd share my experience. -- 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 https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
