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.
>
>
>> 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(: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.
> 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, p.name from jsec_user u join wiki_page p on p.user_id=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.
Jeremy
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sequel-talk/-/DG3nYW_R4VEJ.
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.
