Five Common Rails Mistakes

http://www.mikeperham.com/2012/05/05/five-common-rails-mistakes

by vamsee • 14 years ago

77 29 14 years ago

cageface2• 14 years ago

Without schema constraints, your data will slowly corrode due to bugs in your codebase until you can’t depend on any fields being populated.

Don't tell that to the NoSQL people.

use :limit => N to size your string columns appropriately. Strings default to 255 characters and phone probably doesn’t need to be that big, does it?

Is this a Rails limitation? A lot of DBs, like Postgres, treat all strings as varchar anyway.

kondro• 14 years ago

How big do you think an index on a 255 character string is (at least in MySQL)? And if you're not putting limits on your strings, do you think it's likely you're putting limits on your indexes?

cageface2• 14 years ago

I avoid MySQL as much as possible, so I couldn't say in that case. However, according to the Postgres docs:

http://www.postgresql.org/docs/9.1/static/datatype-character...

The fixed-size field is actually slower in their implementation.

joncooper• 14 years ago

If you use a NoSQL database in production for an extended period of time, you will definitely end up writing code to explicitly manage schemas. Either in the form of data migrations or in the form of DAO code with giant suppurating piles of conditionals.

chris_wot3• 14 years ago

I'm interested in point 4: use SQL. Is there a way of doing a find that only returns the primary key value and then do a delete only based on this value without using SQL and only via Active Record?

xentronium2• 14 years ago

Do you mean something like this?

    ids = Post.where(:published => true).pluck(:id) 
    Post.where(:id => ids).delete_all

or this

    Post.where(:published => true).delete_all

?

chris_wot3• 14 years ago

I looked up the API documentation for pluck... That definitely looks like what I'm talking about :-)

Does the second query translate to a straight DELETE?

janus2• 14 years ago

You might want to use 'destroy' instead of 'delete', as 'delete' skips all ActiveRecord callbacks (i. e., if you had a dependent: :destroy callback for post comments, using 'delete' would leave them intact)

sanderjd• 14 years ago

The second variant seems much better to me - in the first variant the size of the DELETE query itself is proportional to the number of published posts, so for very large numbers of published posts you'll end up sending a lot of data over the network, and may even hit your max_allowed_packet size (though it defaults to 1GB, which would be a lot of published posts!).

sethco• 14 years ago

ActiveRecord::Base#delete_all allows you to delete directly in the database. For example:

  Person.delete_all("created_at < '2012-01-01'")

will generate the sql command

  "delete from persons where created_at < '2012-01-01'"

You can use normal AR conditions of course. For example:

  Person.delete_all(["created_at < ?", Time.now.beginning_of_year])

That will not run any callbacks of course since the data is never being pulled back into your code and AR objects are not instantiated. If you need callbacks to run (for example to delete or update related objects) then look at the much slower ActiveRecord::Base#destroy_all.

lobster_johnson2• 14 years ago

You should be using the new ARel scoping mechanisms introduced in 3.x. See xentronium's comment (http://news.ycombinator.com/item?id=3935050).

cbsmith• 14 years ago

Forgot 6: Using Rails.

DavidAbrams• 14 years ago

Is Rails as prevalent as it once was, or has something emerged to overtake it for whatever it is that Rails excels at?

Five Common Rails Mistakes

Related Stories