rails

There are 39 posts tagged rails (this is page 4 of 8).

Incompatible Rails Local Configuration

Today I experienced a problem when upgrading to rails 4.2 from rails 3.

When updating an Activerecord object with a DateTime value, I've got the following error:

NoMethodError: undefined method `getlocal' for Mon, 01 Jan -4712 00:00:00 +0000:DateTime

I had the following configuration in my Application object:

  config.active_record.default_timezone = :local  # store all values in the local time-zone 
  config.active_record.time_zone_aware_attributes = false # ignore the time zone

I don't want time-zone information for this project.
But getting an error isn't nice so I solved it by enabling the time_zone_aware_attributes.

  config.active_record.default_timezone = :local  # store all values in the local time-zone 
  config.active_record.time_zone_aware_attributes = true # ignore the time zone

Bundler / Passenger strange deployment Issue

Today I tried to deploy our Ruby on Rails application. Environment: Passenger with Ruby on Rails 1.9.3 (via system-wide-rvm) on FreeBSD. Deployment via a simple capistrano script.

After a successful capistano deploy I get the following error when trying to view it in the browser:

Web application could not be started

Could not find rake-10.1.0 in any of the sources (Bundler::GemNotFound)
  /usr/local/rvm/gems/ruby-1.9.3-p392@generalrails/gems/bundler-1.3.5/lib/bundler/spec_set.rb:92:in `block in materialize'
  /usr/local/rvm/gems/ruby-1.9.3-p392@generalrails/gems/bundler-1.3.5/lib/bundler/spec_set.rb:85:in `map!'
  /usr/local/rvm/gems/ruby-1.9.3-p392@generalrails/gems/bundler-1.3.5/lib/bundler/spec_set.rb:85:in `materialize'
  /usr/local/rvm/gems/ruby-1.9.3-p392@generalrails/gems/bundler-1.3.5/lib/bundler/definition.rb:114:in `specs'
  /usr/local/rvm/gems/ruby-1.9.3-p392@generalrails/gems/bundler-1.3.5/lib/bundler/definition.rb:159:in `specs_for'
  /usr/local/rvm/gems/ruby-1.9.3-p392@generalrails/gems/bundler-1.3.5/lib/bundler/definition.rb:148:in `requested_specs'
  /usr/local/rvm/gems/ruby-1.9.3-p392@generalrails/gems/bundler-1.3.5/lib/bundler/environment.rb:18:in `requested_specs'

When I run rake --version in the selected rvm-environment it just exists.
After searching for while I found the following problem:

Passenger gave the following GEM home:

GEM_HOME = /var/usr/local/www/https_www.webpathy.eu/shared/bundle/ruby/1.9.1

When I look in the directory "shared/bundle/ruby" I see everyting is deployed in a directory named: 1.9. The 1.9.1 directory is completely empty!

That's not going to work
WTF!

My quick work-around is the following: 

ln -s 1.9 1.9.1

Now it's running again...
Does anybody know why bundler first deploys it all in "bundle/ruby/1.9" and passenger tries to grab it from "bundle/ruby/1.9" ?!?!?

has_many tricky replace method

Today I discovered a small bug / feature of rails 3.1.3.

Having the following structure:

class Item < ActiveRecord::Base
  has_many :tags
end

class Tag < ActiveRecord::Base
  # Tag has a boolean flag 'enabled'
  belongs_to :item
end

It's possible to completely replace the has_many collection
with a new collection. Make this collection:

item = Item.find(1)
tags = [ 
  item.tags.create( :enabled => true, :name => "tag1" )
]

All fine for the moment. As expected the enabled flag of the first item is set:

tags[0].name      # => "tag1"
tags[0].enabled?  # => true

Now replacing the existing tags:

item.tags.replace( tags )
item.tags[0].name        # => "tag1"
item.tags[0].enabled?    # => false

What?? It just forgot the enabled flag!!

The way to replace the items is by assigning:

item.tags = tags
item.tags[0].name        # => "tag1"
item.tags[0].enabled?    # => true

So remember when replacing collections of has_many do not replace them but assign them....

Rails 3.1 Assets Precompilation

Today I tried to 'release' our rails 3.1 product to the production environment. Which of course has precompiled assets.

The app deployed nicely. But when I tried to start the app, I've got the following error:

ActionView::Template::Error (locales/nl.js isn't precompiled): 
...

Deploying the app with capistrano (which precompiles my assets) did not compile my javascript-locales.

The cause of this seeems to the that the assets pipeline precompilation task, only precompiles the application.js file...

To add extra files for precompilation, place the following code in your config/application.rb:

    config.assets.precompile << "locales/*.js"  
    config.assets.precompile += %w(rails_admin/rails_admin.js rails_admin/rails_admin.css)

This examples precompiles ALL my locale files in the app/assets/locales/* directory.

And as a bonus it also compiles the assets of the the rails_admin plugin.

Ruby on Rails / ChiliProject encoding issues

This week I've decided to exchange Redmine for the ChiliProject. The reason for this is the support for Ruby 1.9. My Apache Passenger server runs Ruby 1.9 so for Redmine I needed a seperate webserver.

When I tried to access the "My Account" page I recieved the following error:

ArgumentError (invalid byte sequence in US-ASCII):
  <internal:prelude>:10:in `synchronize'
  passenger (3.0.7) lib/phusion_passenger/rack/request_handler.rb:96:in `process_request'
  passenger (3.0.7) lib/phusion_passenger/abstract_request_handler.rb:513:in `accept_and_process_next_request'
  passenger (3.0.7) lib/phusion_passenger/abstract_request_handler.rb:274:in `main_loop'
  passenger (3.0.7) ...
`handle_spawn_application'
  passenger (3.0.7) lib/phusion_passenger/abstract_server.rb:357:in `server_main_loop'
  passenger (3.0.7) lib/phusion_passenger/abstract_server.rb:206:in `start_synchronously'
  passenger (3.0.7) helper-scripts/passenger-spawn-server:99:in `<main>'

Rendering /data/www/rails/chili/public/500.html (500 Internal Server Error)

Solution

How should I solve this? The chiliproject has an issue related to this: https://www.chiliproject.org/issues/591.

The following Apache configuration fixed the issue: (The sample is on a FreeBSD system)

I added the following code to a file in the /usr/local/apache22/envvars.d/environment.env

export LC_CTYPE="en_US.UTF-8"

Problems I ruled out or fixed

While trying I also made sure the following things were configured:

I made sure the database is UTF-8. I re-created the database
an ran the migrations again.

create database chiliproject character set utf8;

I used the mysql2 connector instead of the mysql connector in database.yml