Hi,
According to http://guides.rubyonrails.org/active_record_querying.html,
first does not use ORDER BY ID to bring the first record. Whereas
last does.
I find this inconsistent. I can also say that this is buggy on MySQL.
limit 1 does not always bring the record with the minimum id. I can
It is already done at master branch.
https://github.com/rails/rails/commit/66b9e4c857b5987a52f0442ae382ee18dc3dd30a
Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca
On Fri, Feb 22, 2013 at 1:26 PM, Panayotis Matsinopoulos
panayo...@matsinopoulos.gr wrote:
This is already fixed on Rails 4.0
On Feb 22, 2013, at 4:26 PM, Panayotis Matsinopoulos wrote:
Hi,
According to http://guides.rubyonrails.org/active_record_querying.html,
first does not use ORDER BY ID to bring the first record. Whereas last
does.
I find this inconsistent. I can also
Hello,
I know this change made it into 4.0, with a deprecation in 3.2 and was
later reverted (I believe) so as not to deprecate functionality in a patch
release.
I think the intent was for update_attribute to still be deprecated in 4.0.
Is this right?
If so, I've submitted a pull request to do
Hi all :)
Brought this issue to you from here:
https://github.com/rails/rails/issues/9362
Problem is, that rails validations as they are now have a dual nature, they
are something that:
1. helps keep the basic model data integrity (model concept, validate
uniqueness of email on user
Currently (3.2.12), Rails needs 1 separate command per model/migration
to be generated. Each such rails g ... command invokes active_record once.
When a project needs to generate a larger number of models/migrations,
this process can take up lots of time.
So, this...
rails g model_a
On Feb 22, 2013, at 3:53 AM, dosadni...@gmail.com wrote:
https://gist.github.com/bbozo/5006180
This would allow us to handle highly specific controller-introduced
validators inside the controller and without adding unnecessary bloat in
other areas (usually in unit test factories and
If you're unit testing, just create a user bypassing validation:
User.create! :validate = false
That is if you even need a user object at all rather than a stub
To me validations are just fine in models (as in specifying which apply)
along with relationships to other entities. That's pretty
