Equality Query Parameter doesn't need "feq_" prefix

[GoogleCodeExporter]

The equality query prefix "feq_" isn't needed, and makes simple queries fail. I 
made a small patch to let the plain property_name=value syntax work.

For example, this "looks" right, but won't work; it returns zero results. There 
is a "gender" property_name on the User model.

Desired Query: /rest/suds/user/?gender=male 

The current coder requires "feq_", which not natural.

Current Query: /rest/suds/user/?feq_gender=male 

I attached a GNU diff file of the patch on the SVN latest branch (as of 
yesterday). It simply assumes that an invalid operator prefix means "equality", 
and not to ignore the field.

Original issue reported on code.google.com by adroffner on 10 Jan 2012 at 4:23

Attachments:

• rest_query.diff

[GoogleCodeExporter]

unfortunately, that would allow certain property names to cause conflicts with 
some of the other "special" parameters that can be passed to the rest server 
(e.g. offset, page_size, ordering).  even if the server handled that correctly, 
it would lead to very confusing semantics for the user.

Original comment by jahlborn@gmail.com on 10 Jan 2012 at 7:31

• Changed state: WontFix

[GoogleCodeExporter]

I don't think property names to cause conflicts with  the other "special" 
parameters. The ModelQuery.parse() method searches for those "special" 
parameters first, and will not overlook them.

Also, appengine simply ignores any query where the property names do not belong 
to the model. In REST it returns the empty-list, e.g. <list offset=""/>. So, 
there is no greater loss to this query syntax than a client who sends a bad 
query.

Original comment by adroffner on 13 Jan 2012 at 7:16

[GoogleCodeExporter]

yes, i realize that the conflicting property names would be "handled", but it 
would lead to confusing semantics, e.g.: you prefix the operator to the 
property name, except you can drop the prefix if it is "feq_", except if that 
property conflicts with a special query param in which case the "feq_" prefix 
is required.  in short, i'm all in favor of more features and better usability, 
but there is no feature gain and a very miniscule usability gain at the cost of 
some potentially very confusing usage semantics.

i realize this is a "small" feature, but looking at the big picture, it is 
another bit of complexity in an already feature-ful project.  each new feature 
needs to be weighed against how it impacts the entire project.  in this case, i 
don't really buy the "it looks right" argument since it will look different 
from all the other operators, which don't really look right either because the 
overall query support is handling a much more complex query structure than what 
the url syntax was built for.

Original comment by jahlborn@gmail.com on 14 Jan 2012 at 12:06