Posted by rick July 20, 2007 @ 03:11 PM
The MySQL-dump blog posted on some observed rubyisms while evaluating a large ruby application. He highlights some potential problems with ActiveRecord that may come up, such as using “SELECT *”, character sets, unsigned integers, and constraints.
Ruby on Rails was created by David Heinemeier Hansson, a partner at 37signals,
then extended and improved by a core team of committers and hundreds of open-source contributors.
Rails is released under the MIT license. Ruby under the Ruby License.
"Rails", "Ruby on Rails", and the Rails logo are trademarks of David Heinemeier Hansson. All rights reserved.
|
Sponsored by |
 |
Link is broken.
http://mysqldump.azundris.com/archives/72-Rubyisms.html
Most of this is just a list of things people already should be doing where appropriate. However, one thing I highly agree with is his section on UPDATE statements.
Regarding UPDATE:
http://groups.google.com/group/rubyonrails-core/browse_thread/thread/dc2d301dd9c8e5c9
UPDATE issue is not an issue when _select used in find. Because if not, then select * was used and might be your code made some business logic decisions based on retrieved values and when you save – you want to preserve that business state – otherwise – unexplainable behavior when you are trying to do a forensic investigation.
Sounds like the standard DBA position on Rails.
A few observersations though: The issue with show fields should only be an issue in development, which therefore means it’s a non-issue. As far as SELECT *, isn’t that what the :select option is for? Aside from that, the other stuff is OK, but said many times before. I hope he created patches for all the issues, because he who complains…
Definitely good issues to be aware of. I think AR is pretty good about exposing SQL to allow optimization on a case-by-case basis. Rails developers should definitely know their DB stuff and not be using ActiveRecord as a crutch.
Unfortunately ORM is a pretty leaky abstraction due to the parity mismatch between the relational and object-oriented paradigms. Optimizing ORM quickly devolves into an inefficient and bug-prone exercise in futility. That’s not to say some things can’t be fixed, just that not everything is worth fixing.
The article claims using utf-8 in MySQL is very wasteful. I’ve googled around a bit but not found an answer, can anyone here confirm this?
I always assumed utf-8 was just stored as the one byte per character (unless, of course, it’s a special character, in which case it’s ok, my language (Dutch) uses very few of those)
Love begins at home :-)
Here we go – http://dev.rubyonrails.org/ticket/9046 for a start.
@fjan: I can’t confirm that UTF-8 is slower (in theory, it should be the same…but I never trust theory with DBs).
I think encouraging latin-1 is completely backwards in all cases. Even if slower, Unicode needs to be encouraged at all levels.
Pratik, that was a nice try, but it was already there :)
Is Rails quoting stuff in queries yet? Maybe someone can patch that?
There are were a few experienced presenters at RailsConf 2007 that were talking about some of the issues with ActiveRecord…..I hope their concerns will be discussed and addressed in future releases of Rails.
I’m pretty confident it will happen, because the community is pretty cool.
my kingdom for a Ruby SQLAlchemy.
Yeah, nobody has any right to complain about anything in Rails until they’ve dedicated hours of their life to writing patches which the framework’s maintainers will either blindly reject out of egotism or partially accept in some incomplete, perverted form which introduces even more problems they refuse to acknowledge or document in any way.