Em 26-04-2012 22:16, Jeremy Evans escreveu:
On Thursday, April 26, 2012 3:22:07 PM UTC-7, Rodrigo Rosenfeld Rosas
wrote:
This is not about laziness. In a far future I hope to get all my
application converted from Grails to Rails. After that I'd like to
write a migration that would rename the "jsec_user" table to
"users". I'd only need to change a single line of code when I do that.
Using Model.table_name should work fine for that case.
This is not the first project I have this need and I don't think
I'm the only one with such needs. Actually this is far common to
anyone used to deal with SQL and reports. I needed things like
that all the time too in my old job with different projects.
If other Sequel users on this list have a need for this, please speak
up. In general, hard coding the table names in queries is unlikely to
have a negative effect, and if you choose to rename later, it's not
like you won't be able to find related code via grep jsec_user.
Yes, I know, but if this could be added to Sequel, it would be
easier for others to figure out what this method does. I wouldn't
know where this method comes from if I wasn't the one who is
requesting it. I mean, if I was reading someone else's code, I'd
look for "as" in the Sequel documentation and finally would ask
here about it.
The assumption that the need of any user should be added to a library
for all users leads to bloat. It's not like what you want to do isn't
possible currently. It's just that there isn't a shortcut for it. I
don't think a shortcut should be added by default, but you are free to
add such shortcuts yourself.
Okay, I'll create a plugin for that.
It is just that I think this is pretty useful to many people and
wouldn't hurt Sequel anyway.
Most users who submit such feature requests probably feel the same
way. :)
My issues with adding Model.as:
1) What is the behavior if the model references multiple tables
(either FROM and/or JOIN)?
Humm... I don't even know it was possible for a model to have multiple
tables in the from clause. "as" or "alias" should only change the from
clause, not joins. But if it makes sense for a Model to use a FROM with
multiple tables, then you're right.
2) What is the behavior if the model already uses an aliased table?
The alias should change. At least this is what I would expect.
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.
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.
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.
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.
Best,
Rodrigo.
--
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.
