what is sql generated for the proper fix?
attached is a patch that attempts the wrapper solution. (seems to work for
both union/non-union selects)
it basically does the following.
wrap the original select (be it union or not) in _msorg
if the original select has an order_by_clause,
adapt
the line
orderby = wrapper.order_by_clause = sql.ClauseList(*map(
wrapper.corresponding_column, select.order_by_clause.clauses))
should most be
orderby = sql.ClauseList(*map(wrapper.corresponding_column,
select.order_by_clause.clauses))
not exactly sure why i did that...
new diff attached
On Jul 15, 1:02 am, SamDonaldson [EMAIL PROTECTED] wrote:
Not to ask to many questions here but isn't there a standard value for
this? I mean, who would want their db connections to close
unexpectedly like this, especially on a live site? Is there a value
you recommend because this is
fixed a bug that exists if limit isn't specified.
things should be fine now...
On 15/07/07, lei you [EMAIL PROTECTED] wrote:
the line
orderby = wrapper.order_by_clause = sql.ClauseList(*map(
wrapper.corresponding_column, select.order_by_clause.clauses))
should most be
orderby =
sorry about the flood...
this should have the limit/offset is None case fixed.
On 15/07/07, lei you [EMAIL PROTECTED] wrote:
fixed a bug that exists if limit isn't specified.
things should be fine now...
On 15/07/07, lei you [EMAIL PROTECTED] wrote:
the line
orderby =
Hi all, and thanks for the replies: got things to work now!
FYI: If I had the choice, I would definitely use a shared primary key.
Unfortunately I am working off a legacy database so that is not an
option. Neither is renaming DB columns. So I went for the rename
columns on the mapper solution.
Hi all again,
Trying to deploy polymorphic inheritance, I am now hit by what may be
another bug: it seems like getting polymorphic objects may be 100
times slower than regular ones.
I reproduce the problem in the copy-pastable script below, using a
single table polymorphic inheritance
thought it might. In my little MCV world, it's part
of M, not C or V and I wanted to keep it that way as much as
possible. It still is, just not in SA.
i have similar thing into the M/odel, but it is pre_save(), not
after_load(). So it's easier, and done by the sa-managing wrapper.
Though
not an option. Neither is renaming DB columns.
i was talking of renaming the column-names of SA/app, not those in the
db.
see key arg of Column():
key
Defaults to None: an optional *alias name* for this column.
The column will then be identified everywhere in an
SQLAlchemy 0.3.9 Released
Version 0.3.9 of SQLAlchemy is released. This is probably not the last of
the 0.3 series, but it's the last major set of changes for this line;
subsequent releases should probably be only for important bug fixes.
0.3.9includes a lot of important bug fixes as usual, but
- Using polymorphic, joined-table inheritance ? Forget about
polymorphic_union(), just join all the tables together using
outerjoin(). In 0.4, even the select_table argument becomes
optional.
i am not sure if i got this right (a month already). A-B-C works, yes.
But just explain to
On Jul 15, 2007, at 3:03 PM, [EMAIL PROTECTED] wrote:
- Using polymorphic, joined-table inheritance ? Forget about
polymorphic_union(), just join all the tables together using
outerjoin(). In 0.4, even the select_table argument becomes
optional.
i am not sure if i got this right (a
Hello,
I'm running into a hang case on issuing an INSERT to mysql. Here's
some code. Note that I don't really use sqlalchemy sessions or query
objects or anything, I've written my own...I'm only using sqlalchemy
for connection management. So in some file foo.py, I have the
following:
All of
- Using polymorphic, joined-table inheritance ? Forget
about polymorphic_union(), just join all the tables together
using outerjoin(). In 0.4, even the select_table argument
becomes optional.
i am not sure if i got this right (a month already). A-B-C works,
yes. But just explain
Ok. This did not work and I dug this thread where you had a
discussion on this. It seems like this was fixed in sqlalchemy and
you were calling rollback twice which caused this issue.
http://groups.google.com/group/sqlalchemy/browse_thread/thread/9412808e695168ea/c31f5c967c135be0?lnk=raot
I haven't done any research on the mysql end yet but my question is,
why not disable the wait_timeout option on the mysql end to avoid such
connection closing from the server side. Wouldn't this problem go
away all together? Why would you ever want to close idle connections
in such a way? If
SamDonaldson wrote:
[...]
I have defined a transaction decorator:
def transaction(func):
def do(*args, **kw):
connection = engine.connect()
transaction = connection.begin()
try:
# create some context here for the connection and pass it
through to
On Jul 16, 12:50 am, [EMAIL PROTECTED] wrote:
i was talking of renaming the column-names of SA/app, not those in the
db. see key arg of Column():
Thanks for the tip! I tried it and that works too.
For reference, here is what my renaming the SA columns
implementation looks like:
person_table
I see the problem here. So what you're saying is that I need some way
of knowing what the parent connection object was to pass through the
decorators and the execute for the nested txn's should happen on the
same connection object. My follow up question is: how do people
usually implement this
Say I used the threadlocal strategy here. What would the effect of
the following nested calls since I use a decorator? Would it detect
and use the same connection and the same top level transaction?
engine.begin()
do something
engine.commit()
else
engine.rollback()
Thanks for your help in
Hi Michael,
I figured out the problem. It was a connection sharing issue. Looks like
different connection objects were getting returned from the pool (which was
created using the creator approach in create_engine()) when relations were
getting loaded as a part of processing. Due to this sometimes
21 matches
Mail list logo
