We do support something silimilar:
db(Query(db, db._adapter.EQ, db.mytable.myfield, value))>select()
but it is not advertised because this is an internal issue and do not
promise backward compatibility.
We also support
>>> e = Expression(db,"mytable.myfield LIKE 'value' ")
>>> db(db.mytable)(e)
And what if DAL supported statements like this? I think it doesen't by
now:
db(Query(db.mytable.myfield, "mystringoperator", myvalue)).select()
Would that be a possible to implement, enhanced way of querying the
database for the framework?
Does it follows B. Will A option?
On 17 dic, 16:18, Mass
I am reading this over and over... "a == b is a boolean". I know what
you mean but it may be confusing to other users so I will clarify.
It is a boolean when a and b have values, else it is just an
expression. In dal, "a==b" is a query (an expression) that is
evaluated on every record and if it ret
> @Alan Etkin
> Actually, (db.mytable.id == 3) is neither a tuple or a bool. The ==
> operator used on a field returns a Query object.
Yes, you are right, what i was trying to say is that this:
(a == b).select()
is more confusing to me than the normal web2py instruction because in
a python progr
I'm new to web2py and python, but if this argument is purely
syntactic, I thought it would be
db(table.id > 0).select()
rather than
(db.table.id > 0).select()
Nonetheless, I'm good with what we have now, especially the ample
examples in the web2py book to help me get up to speed. DAL is great!
>
> Last argument, I promise.
I won't hold you to that. :-)
> The existence of Query and Set objects are not a hidden implementation
> details. For example, if the user is unaware of the presence of Query
> objects, db(db.mytable.id == 3) shouldn't make any sense, as
> db.mytable.id == 3 shou
Last argument, I promise.
Here's my version of your summary:
1. We have a connection object that represents a database.
2. From the Fields associated with this connection, Queries are
produced with Field's overloaded operators. Queries can also be
produced from combination of other Queries with
> >> Something like:
> >> (db.mytable.id == 3).ignore_common_filters().select()
>
> > A bit ugly, and gets worse if we add more arguments in the future.
>
> Say in our API that we have a Cat type with some uncommon options for
> users to set. Which is the better approach for setting these o
Apologies for dragging this out. I don't mean to be combative, but...
@pbreit
It's weird if you're told OR if you think about it (especially if you
aren't already very fluent in Python). If no one tells you, and if you
don't think about it, it's probably fine. Also, the query already
encapsulates
On Dec 16, 2011, at 1:44 AM, Brian Will wrote:
> I concede that for web2py's current user base, this is a minor point
> of null concern, but I feel it's a notable blemish in an otherwise
> exceptionally clean and well-thought-out API, and a few blemishes like
> this here and there can represent se
On Friday, December 16, 2011 12:45:12 AM UTC-5, Brian Will wrote:
>
> Something like:
>
> (db.mytable.id == 3).ignore_common_filters().select()
>
A bit ugly, and gets worse if we add more arguments in the future.
> Or:
>
> (db.mytable.id == 3).select(ignore_common_filters=True)
>
Not i
It just seems like you'd need to be told that db() is weird to think that
it is weird. It would be difficult to come to the conclusion that db() is
weird without instruction. Doubly so if you are accessing multiple
databases.
@pbreit
> Can't you just explain to people that this is how you query the db:
>
> rows = db(db.item.id==1).select()
>
> How much is gained by dropping the "db"?
Programming is all about taking comprehensible pieces and piecing them
together for your own purposes. A rote formula of syntax tha
I'm admittedly a novice but I don't find db(db.item.id==1).select() very
difficult to understand.
(db.item.id==1).select() is kind of like ' '.join(li) that is so confusing
to Python newbies.
Can't you just explain to people that this is how you query the db:
rows = db(db.item.id==1).sel
Something like:
(db.mytable.id == 3).ignore_common_filters().select()
Or:
(db.mytable.id == 3).select(ignore_common_filters=True)
'One way of doing it' is an argument for fixing it and officially
deprecating the old way. I'd sympathize with the objections more if it
meant actual legac
yes. Only one way of doing things. db(...) does not add too much
syntax.
Moreover db(..., ) allows space for example arguments to be passed
to the query for example db(query, ignore_common_filters=True) so
omitting the db(...) would be a shortcut with decreased functionality.
Massimo
On Dec 1
>
> @Anthony
> > Though I believe it joins tables by using the WHERE clause (as opposed to
> > JOIN, which is used when you pass the "join" or "left" argument to one of
> > Set's methods).
>
> When SQL does that, it itself is doing an implicit JOIN. It's really
> just a syntax convenience. The JOI
@Massimo
So I'm not crazy, at least. Perhaps you can just add the Query and
Table methods, leaving Set "deprecated" but never removed. Isn't this
the current policy anyway? New learners would have a more sensical API
while existing users could stick with what they know. Learnability is
one of web2p
On Thursday, December 15, 2011 12:30:43 PM UTC-5, Massimo Di Pierro wrote:
>
> I have proposed this once and there was opposition to the change.
Do you recall the arguments against?
I have proposed this once and there was opposition to the change.
On Dec 15, 1:46 am, Brian Will wrote:
> The problem is that Set is superfluous, oddly named, and thereby makes
> the whole DAL confusing to learners. I experienced this confusion
> myself when learning web2py, and now I find it's a
>
> A Query is not, as some web2py docs claim, just a WHERE clause. It
> superficially resembles a WHERE clause, but it also implicitly encodes
> the joining of tables.
>
Though I believe it joins tables by using the WHERE clause (as opposed to
JOIN, which is used when you pass the "join" or "lef
Sorry, that is more likely to be a bool object with a select() method.
Since a single comparison is supposed to return such object and not a
sequence
On 15 dic, 10:14, Alan Etkin wrote:
> > (db.mytable.id == 3).select()
>
> It appears as a one length tuple that has a select() method.
>
> Wouldn't
> (db.mytable.id == 3).select()
It appears as a one length tuple that has a select() method.
Wouldn't such changes bring compatibility issues with former formats?
23 matches
Mail list logo
