Em 27-04-2012 13:19, Jeremy Evans escreveu:
On Friday, April 27, 2012 5:31:16 AM UTC-7, Rodrigo Rosenfeld Rosas
wrote:
Em 26-04-2012 22:16, Jeremy Evans escreveu:
3) There is already a Dataset#as method that does something
different, and many Model class methods call the dataset method
of the same, so adding a Model.as method that returns a modified
dataset would introduce an apparent inconsistency.
Sorry I couldn't understand this. If you don't mind, an example
might help here.
Many model class methods just call the dataset method with the same
name. For example, you can do:
Model.where(...)
instead of:
Model.dataset.where(...)
But since Model.dataset.as already exists and operates differently
than your proposed usage (returning an
Sequel::SQL::AliasedExpression), Model.as would appear inconsistent in
this regard.
Humm... what does it do? Believe me, I tried to look for "as" in the
Dataset documentation but couldn't find it:
http://sequel.rubyforge.org/rdoc/classes/Sequel/Dataset.html
What is this useful for?
I could only find this:
http://sequel.rubyforge.org/rdoc/classes/Sequel/SQL/AliasMethods.html
But its documentation suggests a different usage than Model.dataset.as().
Exactly, but it is not great for me to depend on Sequel's
internal if I use something like "where(user1__name)". Also,
"user1__name" doesn't make any sense when reading the code.
Alias are meant to give some meaning to that table role in
the query.
Well, you can use the :graph_alias_base option to set the base of
the alias name per association.
This has to be set in the association definition. But usually they
will have different meanings in individual queries.
Well, I'm not sure about "usually", but I suppose it's possible.
You can't use a hash for eager_graph as you propose, as that is
already valid syntax that means something different (cascaded
eager loading).
Yes I knew about that and wasn't expecting that syntax to be
accepted. I was just telling the idea. That is because my first
idea was something like this:
.eager_graph(:user.as <http://user.as>(:u), ...)
But that means that I'd have to use it like
.eager_graph(Sequel.as(:user, :u), ...)
And I was trying to avoid making it look so verbose.
Well, providing an AliasedExpression to eager_graph could
theoretically be a way to implement what you want (as it is currently
invalid). Looking at the internals, it would require some
refactoring, but at least it's a possibility.
Well, if there isn't a less verbose alternative for those using Sequel
without the core extensions, I would be fine with it.
Maybe I could alias Sequel in my application to S.
So, instead of Sequel.as(:user, :u), I'd use S.as(:user, :u) and
S.~(email: nil).
Relying on the deterministically generated name is fine, it's not
an internal detail that will change. It won't change, you can
consider it part of the spec.
Yeah, now that I read it in the documentation I agree. But still,
where(:user_1__name) wouldn't make much sense to me.
If you have a real world use case where this is causing problems,
please do post it.
Okay, right now this would be only a convenience for helping me
writing the query as I would in SQL.
for example, the common approach in SQL would be something like this:
select u.name <http://u.name>, p.name <http://p.name> from
jsec_user u join wiki_page p on p.user_id=u.id <http://u.id>
With sequel I currently get this as (in PostgreSQL):
select "user"."name", "page"."name" from jsec_user "user" join
wiki_page "page" on ("page"."user_id" = "user"."id")
This doesn't seem to make a huge difference for this simple case,
but I have some really long "where" clauses that it would make it
much simpler to write just :p__name instead of :page__name. That
is because I have some classes like TimeSpentWithClient that would
require me to write code like :time_spent_with_client__start_time
where I'd prefer to write it as :t__start_time in my where clauses.
I'll consider a patch that has eager_graph treat AliasedExpressions
as overriding the alias base to use for the given association.
Great, thanks. I'll try to work on such patch as soon as I find some
free hours.
Thanks!
--
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.
