on a side note, here or for the query(), once i add .order_by() and
similar, will be a possibility to remove/cancel them?
e.g. .order_by(None) - similar to .join(None)?
or should i keep a copy at the point before adding .order_by()?
e.g.
i want:
q1 = query.filter( ...).order_by(z)#the
svilen ha scritto:
on a side note, here or for the query(), once i add .order_by() and
similar, will be a possibility to remove/cancel them?
e.g. .order_by(None) - similar to .join(None)?
or should i keep a copy at the point before adding .order_by()?
e.g.
i want:
q1 = query.filter(
svilen ha scritto:
on a side note, here or for the query(), once i add .order_by()
and similar, will be a possibility to remove/cancel them?
e.g. .order_by(None) - similar to .join(None)?
or should i keep a copy at the point before adding .order_by()?
e.g.
i want:
q1 =
svilen ha scritto:
because q1 with the order is _the_ query, made at point A somewhen,
and stored there as a construct; much later at some point B i need to
use that query but without the ordering - now i have to keep 2 copies
of the query, w/ and w/out order. And this strip-the-ordering
Beyond the API littering, there may be instances where it is difficult or
impossible to remove a query attribute, because adding the attribute caused
a join calculation or reordered parenthesis, or whatever.
The second pattern is better, e.g. save a copy, rather than mucking things
up with
it's not about littering API / namespaces or not, but if u percieve it
just as such... nevermind.
i admit that undoing some change can be difficult or just impossible
in certain cases. So i'll do a sort of command pattern then, keeping
intermediate queries.
Forget that i asked.
Beyond the
On Jun 5, 2007, at 10:30 PM, Mike Orr wrote:
I do think .append_whereclause should be changed to .append_to_where.
A SQL statement can have only one WHERE clause; what you're actually
appending is an AND operand. .append_to_where seems to get that
across better than .append_whereclause or
On Jun 6, 8:32 am, Michael Bayer [EMAIL PROTECTED] wrote:
On Jun 5, 2007, at 10:30 PM, Mike Orr wrote:
I do think .append_whereclause should be changed to .append_to_where.
A SQL statement can have only one WHERE clause; what you're actually
appending is an AND operand. .append_to_where
Yeah, I'm +1 on .where() as well.
On 6/6/07, Michael Bayer [EMAIL PROTECTED] wrote:
On Jun 5, 2007, at 10:30 PM, Mike Orr wrote:
I do think .append_whereclause should be changed to .append_to_where.
A SQL statement can have only one WHERE clause; what you're actually
appending is an
just to note, I am leaning towards very simple generative method
names for all the things we need, where(), having(), order_by(),
group_by(), distinct(), etc. I am going to have it do copy on
generate by default.
the copy operation itself will be pretty quick, working the way I
have it
.where() is OK.
On 6/6/07, svilen [EMAIL PROTECTED] wrote:
q2 = q1.order_by(None)#used sometimes e.g. for count
This would be useful. If a second .order_by can replace the ordering
(as opposed to appending to it), I don't see why it would be difficult
to delete it. .order_by shouldn't
On 6/6/07, Michael Bayer [EMAIL PROTECTED] wrote:
just to note, I am leaning towards very simple generative method
names for all the things we need, where(), having(), order_by(),
group_by(), distinct(), etc. I am going to have it do copy on
generate by default.
If a generative default can
While those who prefer the latter can do that, and if you really
need a copy:
q = q.clone().order_by(...)
explicit is better than implicit is one rule that may apply here.
Not that i enslave myself with those rules but they do make sense in
most cases in the long-run.
Michael, u hold
I want to wake this thread up again. can we get some arguments pro/
con to converting select() to work in a generative style ?
generative means either just the first, or both of these two things:
- methods like append_whereclause() return a select object with
which to call further genreative
hmm, actualy, in such
select.append_whereclause().order_by().group_by().whatever1
().whatever2()...
What is the point of anything except the very first funccall to be
generative? the direct results are thrown away, and the copies are
used - whyfore?
(i guess this applies to query() as
Michael Bayer wrote:
I want to wake this thread up again. can we get some arguments pro/
con to converting select() to work in a generative style ?
generative means either just the first, or both of these two things:
- methods like append_whereclause() return a select object with
which to
On 6/5/07, Michael Bayer [EMAIL PROTECTED] wrote:
I want to wake this thread up again. can we get some arguments pro/
con to converting select() to work in a generative style ?
generative means either just the first, or both of these two things:
- methods like append_whereclause() return
On May 9, 2007, at 4:08 PM, Rick Morrison wrote:
Hey Mike,
I've really gotten to like the generative style of query building
that the ORM layer uses, and I find myself developing a number of
patterns that use that style to
good advantage.
Today I found myself struggling with a query
18 matches
Mail list logo
