On Mar 1, 11:54 pm, David Lee <[email protected]> wrote:
> I do like your solution in that it gives users the flexibility to
> specify the WHERE clause in two different ways, but I think it might
> be better having separate methods. The reason I proposed separating
> filter and where was because #filter sounds like a Ruby term, whereas
> #where sounds like SQL. I thought it would be nice to support the Ruby-
> ish way of filtering through #filter while supporting the SQL-ish DSL
> through #where.
>
> # Looks like Ruby:
> dataset.filter {|x| x.price > 1}
>
> # Looks like Sequel:
> dataset.where {price > 1}
>
> This way, it is also easier to explain to users that #where does an
> instance_eval on VirtualRow, whereas filter simply does a yield--
> without condition on the arity of the block. You can say, "use #filter
> to filter the dataset like an array; use #where for a SQL-like DSL."
I see your point, but I still think they should remain the same.
> By the way, have you thought of extending the DSL to be able specify
> table.column without using the double underscores?
>
> dataset.where {(users.id == posts.user_id) & (users.name < "M")}
> # => "users.id = posts.user_id AND users.name < 'M'"
That's interesting. I've thought of doing something similar for
functions that take no arguments (currently you have to use
sql_function for that), but I wasn't sure it was a good idea. I don't
like the use of ==, though, as users may think they can do != (which
can't be made to work on ruby 1.8).
In order for this to work, you'd need VirtualRow#method_missing to
return a subclass of VirtualRow that was literalized like an
identifier but also used method_missing to return another instance of
the subclass with the current identifier as the qualifying identifier
and the method called as the qualified identifier. You'd also want it
to handle schemas. Example:
DB.literal(Sequel::SQL::VirtualRow.new.a) # "a"
DB.literal(Sequel::SQL::VirtualRow.new.a.b) # "a"."b"
DB.literal(Sequel::SQL::VirtualRow.new.a.b(1, 2)) # "a".b(1,2)
DB.literal(Sequel::SQL::VirtualRow.new.a.b.c) # "a"."b"."c"
The problem I have with this is that you end up with objects that
respond to method_missing leaking into other parts of Sequel, which
can make debugging more problematic. Currently, since
VirtualRow#method_missing only returns Identifiers and
QualifiedIdentifiers, that's not something I have to worry about.
The syntax is cool and natural, but I think this may be too much
magic. I'd like to see a plugin or extension with this and get buy-in
from the community before I'd consider adding this to Sequel itself.
Jeremy
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sequel-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
