(Query).select()

[Paolo Valleri]

Hi all, 

with the following patch: https://github.com/ilvalle/pydal/tree/new_query_syntax

It is possible  to write queries as

(db.tt.id == True).count()

(db.tt.id == True).select()

without the common call to db

db(db.tt.id == True).count()

db(db.tt.id == True).select()

It seams to work well with the object Query and we can obtain the same behavior for both

- (db.tt).select() 

- (db.tt.id).select() 

by adding a similar code in Table.__getattr__ and Field.__getattr__

The missing part regards ignore_common_filters because the following is incorrect (db.tt.id == True, ignore_common_filters=False).select()

Given that, this proposed syntax is not 100% compatible with the actual one, unless ignore_common_filters is specified somewhere else 

What do you think?

 Paolo

[Massimo DiPierro]

I have proposed this long ago and there was opposition to this. because it broke the “one way of doing things”.

Perhaps sentiment has changed? Also db(…., ….) can take additional named arguments therefore the new syntax if adopted is more limited.

--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---
You received this message because you are subscribed to the Google Groups "web2py-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marin Pranjić]

It looks uglier and sparing two letters means nothing to me.

Are there any benefits?

Marin

--

[Anthony]

What are the benefits besides saving typing "db"? If that's it, I'm not sure it's worth the possible confusion with having two ways to do the same thing, particularly since the new way loses some functionality (i.e., ability to specify arguments that modify the query, and ability to chain sets via the __call__ method -- though I suppose the latter could be added).

In terms of clarity/API usability, I think db(query).some_method is a little more clear than (query).some_method. For some previous discussion on the matter, see https://groups.google.com/d/msg/web2py/cEcRhobPv8A/YBjsxz7lvmkJ.

Anthony

[Niphlod]

IMHO, +1 for shortcuts and +2 for consinstency, which sums up to -1 for the proposal, sadly. 

I get tired too to have zillions of "db", "db2", "db3", "db4" all over the place, plus gettattr()ing 4 times to get a field attribute (db.table.field.attribute), and in fact my code is usually full of

tb = db.table

and, unfortunately,

db(tb.id>0).select()

that could be turned "automagically" to 

(tb.id>0).select()

but sparing a db (or db2, db3, db4) is not worth the gain vs a good autocomplete editor. I'd probably drop dead the second someone would ask me to use the admin app vs sublimetext: yes, I'm spoiled but it works fine.

[Michele Comitini]

This would be without "db" redundancy

db((t1.f1 == True) & (t1.f2!=True))

Impossible to digest for python!

But the day the DAL will support cross engine joins the following would work in python but unclear about what callable (db1, db?) needs to be used 

db1((db.t1.f1 ==True) & (db1.t1.f1==True) & (db.t1.f2==db1.t1.f2))

Iff that would ever be possible then Paolo and Massimo "shortcut" would be the correct one.

--

[Paolo Valleri]

Hi all, I didn't know that almost 4years ago someone else proposed the same.

This proposal is not about saving to write two letters (even if in a project I have few db_name, which is a pain to write in each query).

It simply seems to me more natural mentioning the db only once. As Michele has shown, the opposite "db((t1.f1 == True) & (t1.f2!=True))" is not possible in python

As a result, since Query already knows the db, is possible to bypass db.__call__

@niphload, +1 for shortcut +2 for consistency, doesn't sum up to -1 but 3. Or did you mention -2 for consistency ?

 Paolo

[Anthony]

It simply seems to me more natural mentioning the db only once.

If that's the issue, you could imagine an alternative version of Set that doesn't require the db as an argument:

Set(db.mytable.id > 0).select()

That guarantees you never have to type more than three extra letters (I suppose we could change it to just S() or Q() to get it down to one letter), but you can still pass additional parameters. And this is just a personal preference, but I also think it looks better and is more clear if you have something like:

SomeClass(...).some_method()

or:

some_object.some_method()

rather than:

(some python expression).some_method()

Particularly when the Python expression wrapped in the parentheses looks like a boolean (which can lead to confusion).

Also, keep in mind that we can now do:

db('some arbitrary SQL expression').select(...)

In that case, (a) the "db" is not actually redundant, and (b) you could not do ('some arbitrary SQL expression').select().

To accommodate that case, we could have something like:

Set('SQL expression', db=db).select(...)

where specifying the db would be optional, used only when it could not be discerned from the query.

In short, the problem with the current proposal is that we lose both functionality and consistency for seemingly little gain. If we want to avoid redundancy of specifying "db" or having to type long names of DAL objects, a better approach might be to adopt the direct use of the Set class (or create a new class called S or Q).

Anthony

[Richard Vézina]

What's going to hapen to the second side of the query (query).somemethode(HERE) ? Does the proposal allows to drop the "db." ?

What about left=...?

Richard

On Thu, Jul 30, 2015 at 10:09 AM, Anthony <abas...@gmail.com> wrote:

It simply seems to me more natural mentioning the db only once.

If that's the issue, you could imagine an alternative version of Set that doesn't require the db as an argument:

Set(db.mytable.id > 0).select()

That guarantees you never have to type more than three extra letters (I suppose we could change it to just S() or Q() to get it down to one letter), but you can still pass additional parameters. And this is just a personal preference, but I also think it looks better and is more clear if you have something like:

SomeClass(...).some_method()

or:

some_object.some_method()

rather than:

(some python expression).some_method()

Particularly when the Python expression wrapped in the parenthesis looks like a boolean (which can lead to confusion).

Also, keep in mind that we can now do:

db('some arbitrary SQL expression').select(...)

In that case, (a) the "db" is not actually redundant, and (b) you could not do ('some arbitrary SQL expression').select().

To accommodate that case, we could have something like:

Set('SQL expression', db=db).select(...)

where specifying the db would be optional, used only when it could not be discerned from the query.

In short, the problem with the current proposal is that we lose both functionality and consistency for seemingly little gain. If we want to avoid redundancy of specifying "db" or having to type long names of DAL objects, a better approach might be to adopt the direct use of the Set class (or create a new class called S or Q).

Anthony

--