Cleaning out my inbox...
FWIW I'm +1 on removing the old-style methods, +1 on .first instead of
.scalar, +1 on adding .one, and +0 on renaming .list to .all.
Did you make a decision for 0.4 Mike?
-J
--~--~-~--~~~---~--~~
You received this message because you
On 6/12/07, Michael Bayer [EMAIL PROTECTED] wrote:
we have, in fact, made a tip of the hat to SAT analogy questions
(selecting everything is to all() as selecting just the first row is
to: a. scalar() b. first() c. list()[0]).
I've already said it earlier but since you didn't comment on
On 6/3/07, Michael Bayer [EMAIL PROTECTED] wrote:
- filter_by() would gain a new positional argument, which is
optional, which is either a string or list of strings indicating
property names, indicating a join path. when this argument is
present, a self-contained join among those mapped
all seems ok.
and ORM will become looking less SQLish (as .select being the most
SQLish word IMO)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to
These sound like a good progression of the library.
Would there be a way to turn on warnings if one were to use a
deprecated interface? Or if the programmer wants to be even more
strict, raise an exception? This wouldn't be the default, but rather
an available option.
On Jun 3, 2007, at 10:33 PM, Michael Bayer wrote:
one() raises an exception when theres not exactly one result, scalar
() does not. currently we have selectfirst() and selectone(), people
seem to like the dichotomy. [0] specifically adds LIMIT 1 OFFSET 0
to the query and i dont think
The use of scalar() here seems out of place with both the common CS usage of
the word (e.g. scalar == single-valued), and the use of scalar() in the SQL
layer. Single row results in the ORM are rows, not a single datatype. It's
another potential point of confusion, like the ORM .select() is/was.
On Jun 4, 2007, at 9:56 AM, Rick Morrison wrote:
The use of scalar() here seems out of place with both the common CS
usage of the word (e.g. scalar == single-valued), and the use of
scalar() in the SQL layer. Single row results in the ORM are rows,
not a single datatype. It's another
Well, I don't really see the connection between .scalar() and .list(), other
than they are kind of antonyms, but FWIW I always thought that .list() was
an odd duck anyway, seeing as how the arguably more Pythonic list(query)
works fine.
On 6/4/07, Michael Bayer [EMAIL PROTECTED] wrote:
On
Well, I don't really see the connection between .scalar() and .list(),
other than they are kind of antonyms, but FWIW I always thought that .list()
was an odd duck anyway, seeing as how the arguably more Pythonic list(query)
works fine.
(expanding on this a bit)
More generally, it's the
On Jun 4, 2007, at 10:47 AM, Rick Morrison wrote:
Well, I don't really see the connection between .scalar() and .list
(), other than they are kind of antonyms, but FWIW I always thought
that .list() was an odd duck anyway, seeing as how the arguably
more Pythonic list(query) works
On Jun 4, 2007, at 3:27 AM, Neil Blakey-Milner wrote:
The joined tables are aliased as the path from the base object. In
this case, the jobtitle join is:
INNER JOIN strids AS positionprofiles__jobtitle ON
positionprofiles.jobtitleid = positionprofiles__jobtitle.id
The
On Monday 04 June 2007 18:03:05 Rick Morrison wrote:
Well, I don't really see the connection between .scalar() and
.list(), other than they are kind of antonyms, but FWIW I always
thought that .list() was an odd duck anyway, seeing as how the
arguably more Pythonic list(query) works fine.
On 6/4/07, Michael Bayer [EMAIL PROTECTED] wrote:
anyway, the filter on product/store and product/type example you just
mention presents a third scenario, which I wouldnt consider to fall
under the filter_by([attributes]) functionality, it would fall under
the regular join() call which
On Jun 4, 2007, at 12:09 PM, Neil Blakey-Milner wrote:
What do you think of me putting up the full pathological-case code
from Django ORM and SQLAlchemy on the SQLAlchemy wiki, and maybe see
if there are improvements to be found for that as well (since it uses
ILIKE and not equality and a
On 6/4/07, Rick Morrison [EMAIL PROTECTED] wrote:
The use of scalar() here seems out of place with both the common CS usage of
the word (e.g. scalar == single-valued), and the use of scalar() in the SQL
layer. Single row results in the ORM are rows, not
a single datatype. It's another
That's one of the reasons I prefer to treat Query() like an iterator and
roll my own first-order functions like first() etc. -- see my other
message regarding this.
On 6/4/07, Mike Orr [EMAIL PROTECTED] wrote:
On 6/4/07, Rick Morrison [EMAIL PROTECTED] wrote:
The use of scalar() here
On Jun 4, 3:11 pm, Mike Orr [EMAIL PROTECTED] wrote:
.first() -- returns first row
.one() -- returns first row, raise exception if more than one result
What if there are zero rows? Return None or raise an exception? I
find the former useful enough, but I imagine some people prefer the
Well, that answers my next N anticipated questions on this list plus
essentially every unasked-yet one in my backlog. These consistency/
predictability-of-syntax/redundancy points cut to the core of every
issue I've had and/or every time I've had to hit the docs for more
than a brief reminder.
On 6/3/07, Michael Bayer [EMAIL PROTECTED] wrote:
- the methods select(), selectfirst(), selectone(), select_by(),
selectfirst_by(), selectone_by() and get_by() would be deprecated.
this means they will remain present on the Query object but the
documentation would be reorganized to talk
On 6/3/07, Michael Bayer [EMAIL PROTECTED] wrote:
- the methods select(), selectfirst(), selectone(), select_by(),
selectfirst_by(), selectone_by() and get_by() would be deprecated.
this means they will remain present on the Query object but the
documentation would be reorganized to talk only
On Jun 3, 2007, at 5:29 PM, Mike Orr wrote:
I would suggest renaming .list() to .all(). It seems funny having a
method with the same name and same behavior as list(query) -- I can
never decide which to use.
list() has been around awhile and is also derived from hibernate's
similar
On 6/3/07, Michael Bayer [EMAIL PROTECTED] wrote:
im giong to look into optimizing the cloning. as ive said,
hibernate's criteria object behaves generatively but doesnt
actually copy the object; several folks here seem to want the
generativeness. ive been considering sneaking in a
23 matches
Mail list logo
