Re: [Rails-core] Improving the ActiveRecord query API

[Rodrigo Rosenfeld Rosas]

Em 07-12-2012 11:44, Ernie Miller escreveu:
> ...
> While the most common usage of Squeel is via instance_eval, and I know
> core is traditionally not in favor of such dark arts, it's perfectly
> possible to use Squeel syntax without instance_eval, as in:
>
> Post.where { |post|
> post.title.like('zomg%') | post.title.like('bbq%')
> }
> # => SELECT "posts".* FROM "posts" WHERE (("posts"."title" LIKE
> 'zomg%' OR "posts"."title" LIKE 'bbq%'))
>

What if a column is named "class"? I'd rather prefer something like that:

Post.where { |post|
post[:title].like('zomg%') | post[:class].like('bbq%')
}

[Rodrigo Rosenfeld Rosas]

Em 10-12-2012 19:40, Ernie Miller escreveu:

On Monday, December 10, 2012 4:08:06 PM UTC-5, Rodrigo Rosenfeld Rosas wrote:

What if a column is named "class"? I'd rather prefer something like that:

Post.where { |post|
   post[:title].like('zomg%') | post[:class].like('bbq%')
}

In Squeel's specific case, the DSL object is a blankslate, so it works fine. Hash-style syntax would be another option. That would avoid method_missing overhead for simple column access, which would be a good thing, but make things less readable, as well. Not my personally-preferred tradeoff, but certainly could see a case for it.

There is a recent (scattered) discussion about this topic on ruby-core mailing list:

https://bugs.ruby-lang.org/issues/4085#note-249

As noticed in that scattered thread, the odd-named columns (such as "dotted.column") aren't my only concern with Squeel approach (when the block has zero arity) as there may be conflicts with local methods and variables/arguments names.

And I don't see much difference (as you state it is less readable) between:

post[:title].like('zomg%')

and

post.title.like('zomg%')


But I find this more consisent:

post[:"dotted.column"].like('zomg%')

than this:

post.__send__(:"dotted.column").like('zomg%')

You could actually support both syntaxes, but if you do so you wouldn't be able to support things like this in the future:

post.like(:some_column, 'some value')

as an alternative to

post[:some_column].like('some value')

Not that I think that would be wanted at some point but maybe we could find some useful methods to define on the dsl object in the future.

With regards to GitHub stars, I wouldn't count much on that. I use GH stars as a global "favorites" thing so that I can quickly find some project I want to cite or take a closer look in the future. Most GH projects I starred I don't actually use.

[Ernie Miller]

On Tuesday, December 11, 2012 6:35:48 AM UTC-5, Rodrigo Rosenfeld Rosas wrote:

But I find this more consisent:

post[:"dotted.column"].like('zomg%')

than this:

post.__send__(:"dotted.column").like('zomg%')

You could actually support both syntaxes, but if you do so you wouldn't be able to support things like this in the future:

I guess I don't follow, here -- do you mean a column with an actual dot in its name? I've been working with SQL for over 15 years, and while I know it's possible to do, I've never encountered a good reason for it. I agree that the first is more consistent in this case, but this seems like the edgiest of edge cases -- and, as you said, could be supported with alternative syntax. Not worried about supporting "like(:column, value)", personally. I like left to right readability when possible.

 

With regards to GitHub stars, I wouldn't count much on that. I use GH stars as a global "favorites" thing so that I can quickly find some project I want to cite or take a closer look in the future. Most GH projects I starred I don't actually use.

Didn't mean to imply much importance for stars, but as a relative metric, it seemed moderately useful -- they are as important/unimportant everywhere. ;)

[Rodrigo Rosenfeld Rosas]

On Tue, Dec 11, 2012 at 9:20 PM, Daniel Azuma <daz...@gmail.com> wrote:

...

There will always be debate on the merits of API design, especially when a DSL is involved, but Squeel is mature and has done an excellent job of navigating the issues as well as providing fallbacks to more traditional syntax. It is more feature-complete than the status quo, and pretty much has no rival when it comes to constructing non-trivial queries.

You're not aware of Sequel, I guess... Or you're only comparing alternative plugins to current AR implementation, right?