Simple tactic for migrations beyond migrate

Make use of Rake in your miscellaneous migration tasks. Migrations are geared for database changes all or nothing is best since backtracking always is risky. Add your own application rake tasks to handle additional record creation, default settings, app specific stuff. Model classes are best for methods since you can test on console and tinker, but once you are there, a rake lib gives better control for the task at hand, lets you add on tasks without affecting the app core. All deployments I’ve used have handles to rake which can be used on demand.

Rails , db performance tip

Just a quick tip for those who have banged heads with sorting issues. In particular when working accross database technologies, you may end up getting bitten by default behavior differences.

So here’s something to keep in mind, Indexes are to Sorting as Hardware is to Software.. You can define default order behavior if you have the right index.

How did this come up recently for me? Sorting differences on a multilayer ed hierarchy of data , never noticed anything until deploying to production which used PGSQL instead of MYSQL

Rails 2.3.5 , Ruby 1.9.1 and plugins …

If you’ve tried installing a plugin from github lately it seems everything’s not found..

As of Rails 2.3.5 there still is a open bug which is getting in the way of happy trails with ruby 1.9.x

Start up a shell with Ruby 1.8.x and install the plugin as usual. Then go back to working with Ruby 1.9.x. The fix will be out on rails 2.3.6 so a bit of patience and this will go away.

(Update) waiting for rails 2.3.6 .. seems rails 3 will be out before this is done

How to connect Ruby 1.9.1, Rails 2.3.5 to SQLServer

annoyingly enough , i had figured out the concept. Use DBI ODBC instead of DBD ADO… now ADO is going through some tug of war bullshit , which eventually will fade out when Microsoft gets its paws untangled

in the meanwhile , there towards the bottom is the answer

updated link

this is signigicant because the dbi gem in Ruby 1.9.1 is already on another version greater than the one desperately needed to make things work.

It should be noted that this version of the adapter was developed using both the ancient 0.0.23 version of DBI up to the current stable release of 0.4.1. Note that DBI 0.4.1 is the minimal for ruby 1.9 compatibility. Because later versions of DBI will be changing many things, IT IS HIGHLY NECESSARY that you max your install to version 0.4.1 which the examples below show. For the time being we are not supporting DBI versions higher than 0.4.1 this they settle down on new internal implementations.

Performance is seemingly OK

AMAOF

database integration through Ruby on Rails

Rails has the built in ability to connect to multiple databases.
Short story is, you define databases through the database.yml file, beyond development, test and production. You can define sets of development, test and production databases that connect to any of the supported DB clients provided with Rails.

There are ruby adaptors for all major databases. There’s even ODBC support provided to finish opening up the ability for the DBs to connect.

Couple this with the ability for an AR object to define its own database connection. Add the ability to define an inherited class for an AR model.. Add the ability to set the table name, primary key names to each model.

Finish it up with the rails console.

a smart DBA can really milk this

Custom SSL in Heroku

Heroku allows SSL with Custom Domains. There’s lots of blogs out there lamenting the fact that it doesn’t. May have been true in May, not anymore in Nov.

Ruby on Rails on Windows

For a while now I have been developing on rails on windows, not the happiest choice for all “blog driven development”

My secret to happy trails, Mingw distribution of Git for windows, because it brings what I want, mingw , msys and git. Short story, msys took over the command line, and now I dont have to think in windows shell no more.

Active Scaffold works!

Time flies, I’m glad this plugin has made it through to rails 2.3.4 !!!!

My first rails app is still in use; I just got another couple of years of life injected to it by way of M&A .

Well that’s all good, I’m using this opportunity to upgrade it to rails 2.3.x, set up for friendly deployment etc.

So, Active Scaffold has become my replacement for all the supporting CRUD which used to be drab scaffold based HTML.

Now… small controllers, nicer UI ..

So far the only thing that makes little sense is the not-getting the pluralization rules in the tons of examples and demos found on the site. Which is slightly weird, but WHATEVER, cause it all works.

Integration in a Model?

Well, having done some research on phusion and its memory handling I decided to build the price spider integration for wwhow straight in the model. Not only would I get to drive through the console, the TDD approach suddenly made itself sensible; a suite of quick to do and mantain tests is lovely indeed.

Wwhow talks to Twitter as well, which I’d done at Controller level, for what felt were good reasons then. I refactored the whole thing to the Model instead and then refactored the APIs to be sub classes of a model which I actually do store..

Well, I have no idea what other Rails folks my hate or not about this, but it works for me. This trick makes batch jobs simple rake tasks, cron can do the scheduling. And read up on passenger phusion if you dont believe me.

One quick tip for db performance on Rails

Make sure you add indexes to your migrations. Most of the time db performance problems are SQL related. Most of the time the SQL is fairly innocuous. A lot of the time though, in loading the objects the SQL will work best if the candidate keys on the many side of the equation are indexed columns. Create models through generators and either add the indexes to the added migrations or add new migrations to make sure that not only the id primary key indexes are created, but the supporting indexes (like user_id, tagging_id, rateable_asset_id) are also indexed.

Finally, note that cardinality and composition is important in indexes:
Given an index on column A, index on B, index on C
And a query which searches for conditions on A,B,C , then index A is being used most probably alone. If Index A is a low cardinality index (like a flag) then the query is going to scan the whole index which is just as bad as a full table read. The execution plan will say Index read but performance will be awful . B or C might be even faster choices than A, but by having query look at A and an index on A your query is going to go with the slow performing read.

So make sure your indexes are useful, if B gives better spread than A, and your query is asking for conditons on A,B,C then make your index a composite B,A,C order and the SQL will fly.

All of this of course should be transparent to the app side in rails. All of this can be handled via migrations, and will work equally well on all DB choices Rails provides.