Freezzo.com

I am going to list from the guides.rubyonrails.com site, some possibly less know, but useful configuration options for ruby on rails. I didn’t know these existed until I had to figure out an elegant way to prefix tables with something, and I didn’t want to just type it into the migrations and models. Here is how you set the variables:

In your config/environments/development.rb (or production.rb, or whatever.rb) do the following:

config.active_record.table_name_prefix = "whatever_"

You can also select any of the following options instead of table_name_prefix to configure active record globally. Here is the list:

ActiveRecord::Base includes a variety of configuration options:

* logger accepts a logger conforming to the interface of Log4r or the default Ruby 1.8.x Logger class, which is then passed on to any new database connections made. You can retrieve this logger by calling logger on either an ActiveRecord model class or an ActiveRecord model instance. Set to nil to disable logging.

* primary_key_prefix_type lets you adjust the naming for primary key columns. By default, Rails assumes that primary key columns are named id (and this configuration option doesn’t need to be set.) There are two other choices:
o :table_name would make the primary key for the Customer class customerid
o :table_name_with_underscore would make the primary key for the Customer class customer_id

* table_name_prefix lets you set a global string to be prepended to table names. If you set this to northwest_, then the Customer class will look for northwest_customers as its table. The default is an empty string.

* table_name_suffix lets you set a global string to be appended to table names. If you set this to _northwest, then the Customer class will look for customers_northwest as its table. The default is an empty string.

* pluralize_table_names specifies whether Rails will look for singular or plural table names in the database. If set to true (the default), then the Customer class will use the customers table. If set to false, then the Customers class will use the customer table.

* colorize_logging (true by default) specifies whether or not to use ANSI color codes when logging information from ActiveRecord.

* default_timezone determines whether to use Time.local (if set to :local) or Time.utc (if set to :utc) when pulling dates and times from the database. The default is :local.

* schema_format controls the format for dumping the database schema to a file. The options are :ruby (the default) for a database-independent version that depends on migrations, or :sql for a set of (potentially database-dependent) SQL statements.

* timestamped_migrations controls whether migrations are numbered with serial integers or with timestamps. The default is true, to use timestamps, which are preferred if there are multiple developers working on the same application.

* lock_optimistically controls whether ActiveRecord will use optimistic locking. By default this is true.

This is a follow up to my previous post about clearing out sessions. It turns out I was pulling a lot of crap sessions from rss feeds and xml requests which I didn’t need. I had over 14k new sessions in less than one day. To help combat this, I came up with a solution to turn sessions off based on a request type. I added this to application.rb file:

session :off, :if => Proc.new { |req| ['xml', 'rss'].include?(req.params[:format]) }

You could ideally just add this to an individual controller, and add nly or :except to it as well, but I wanted to eliminate all of the controllers and actions.

I have decided to take a stab at using squidoo effectively, while promoting a clickbank product to hopefully make some sales. I was over at potpiegirl.com and her posts really inspired me to try harder. I contacted her and asked her for some tips, which she gladly helped out with.

I pulled together a squidoo lens, which that in itself can be overwhelming, and came up with a page promoting creating free electricity. I am no expert, so I’m not even sure if what I’m doing will work. Hopefully it works out well!

On a side note, you can follow me on twitter

I’m sure you all know how to use the :conditions attribute when using ActiveRecord:

User.find(:all, :conditions=>['active = ?', true])

And you may even use associations this way:

User.find(:all, :include=>[:photos], :conditions=>['photos.removed = ? and users.active = ?', false, true])

But did you know that you can do this easier through hashes?

User.find(:all, :conditions=>{:active=>true})
User.find(:all, :include=>[:photos], :conditions=>{'photos.removed'=>false, 'users.active'=>true})

Nothing special there, but I thought it was pretty cool. One thing you have to remember when using associations, is to include that model.