On 29 October 2011 18:23, Christopher J. Bottaro
[email protected] wrote:
JOIN events e2
think it might be better to use created_at, if that is what you really
Hmm. Interesting. On the one hand, I’m glad people are looking out for
each other and advice is given on best practices. On the other hand, I
forgot what it’s like to ask for help on the internet and have everything
you do under heavy scrutiny
I did start by apologising for not answering the question
I suspect it may be that for maybe 50% of questions asked here the
best result for the OP is not to have his question directly answered
but to suggest alternative ways of approaching the problem. No I have
not done the research to prove that, it is just my feeling. To answer
a question by suggesting alternatives is therefore a perfectly valid,
and often helpful response.
Presumption incorrect. It is a one off and not routine code, but that
doesn’t stop me from wanting to learn how to better use AR/Arel. Also, I
created a unique index as soon as I realized there were dupes and I cleaned
them out. I also added validation (which isn’t guaranteed to work, hence
the unique index in the db), and test cases/specs for the situation.
OK, I did not realise that this was an academic question. In that
case my suggestion is of no use to you. You never know, it may be of
use to someone else finding this thread in the future, in which case I
have not entirely wasted my time.
About the id vs created_at I disagree and consciously chose the former. I
think either will work fine and it’s ok to make assumptions about the
uniqueness (for sure) and order (comfortably sure) of primary keys for a
given adapter. I’m familiar with the Postgres and MySQL adapters and I know
they create unique, auto incrementing primary keys for each table.
Certainly the id values will be unique, there is no question about
that. I seem to remember reading about the situation with multiple
servers where each server will get given a batch of id values it could
use, so that the id values would not necessarily be in the same order
as created_at. I may be mistaken however. Also consider the
possibility in a few years time of someone migrating the code onto a
different db adaptor. The code might then break.
I think the point is that Rails does not guarantee that id values will
increase monotonically and therefore it is not a good idea to rely on
That said, I am open to notion that I’m wrong or do not fully understand
something though, so
Thanks for the help,
I don’t think I have been much help. I can answer part of the
question though. You ask for the “best/easiest” way to write the
statement. The easiest way is just to code in the sql as you
already have the sql available, so it is easy. I still don’t know
whether there is any better way though. It is certainly not obvious
to me, sorry again.