March 24, 2008 @ 11:36 PM

Rails Migrations in Git Branches

For those of you that don’t stalk follow my other streams:

Migration Buddy

Or, “the inevitable renumbering and conflict-resolution of miggy tardust”

This is a tool to help merge rails branches with conflicting migrations. The basic idea goes like this:

  • First you migrate down to the migration you were at when you branched.
  • Renumber any new migrations you created that conflict with any new migrations in the target branch.
  • Commit the renames.
  • Merge to the target branch (usually ‘master’).
  • Migrate back up.

Wow, what a pain, right? (Apologies to Saul Williams, you rock).

I keep threatening, but I may have to replace this blog with a combination twitter / tumblr / github stream.

13 comments

March 04, 2008 @ 01:00 AM

moving to github

I’ve been using git for several months now, waiting for a reason to keep my svn habits around. So far, it’s been pretty smooth sailing. There were some squalls along the way as I unlearned some habits from svn though. I even moved active development of my various open source projects to git. Well, today I’ve moved most of my “active” (and I say that in the loosest of terms) projects to github.

Github is fantastic, but why?. The core repository browser stuff looks and works great, but is nothing revolutionary, to be honest. What’s amazing about Github is how it really brings the social aspect into play. Chris and Tom are showing us all visually how git development is supposed to work. I know I personally had some bing moments once I started pulling in commits from external git repos.

For what it’s worth, Gitorious is another great community of git hackers. They’ve also added merge requests to the mix since the last time I looked at it. The differences with Gitorious are that it’s exclusively geared for open source projects, and that Gitorious itself is open source. That’s wild.

The great thing about git is that it doesn’t matter which you choose. You can easily add a git remote for both, and keep your origin on your own server. I hope we can see some collaboration between the two in the future. I know Github has some neat web hooks powering some backend processing functions. It’d be interesting to be able to initiate fork requests to your git[hub/orious] account by POSTing a public fetch url, or to send a user a pull/merge request by POSTing to a public end point (or emailing a git mailbox).

Naturally, as the author of Warehouse, I have other reasons for wanting to see this happen. I’d like to be able to collaborate with other git hacker networks and keep my data on my own server. The only way this is possible is if there’s a simple API we can all agree on.

At any rate, I firmly believe that fantastic tools like Github and Gitorious will do a lot to drive git adoption. Having clean, visual tools will go a long way in simplifying git for new users.

Update: Oh yea, I have a couple github invites if anyone wants them.

12 comments

February 13, 2008 @ 03:39 AM

Giles is Proud Not to Understand has_many :through

Apparently, the number of exception classes related to has_many :through (HM:T) scared Giles away. I think most of them are there because I put the original ones there. Course, looking at them highlighted does make it seem a bit ridiculous.

HM:T associations are the only associations that actually look at other associations to figure out how to query the database. There aren’t a simple set of conventions to go by that raise simple errors like “couldn’t find the `suspended_users` table”. If you actually look at the associations, they’re not much more than simple ActiveRecordError subclasses with a custom message. It gives you nice, helpful messages like this:


class Post < ActiveRecord::Base
end
class User < ActiveRecord::Base
end
class Topic < ActiveRecord::Base
  has_many :posts
  belongs_to :user
end
class Forum < ActiveRecord::Base
  # commented out bits are things
  # i conveniently 'forgot' in this contrived example.
  #
  # has_many :topics 
  has_many :posts, :through => :topics
  has_many :creators, :through => :topics# , :source => :user
end

Forum.find(:first).posts
# => ActiveRecord::HasManyThroughAssociationNotFoundError: Could not find the association :topics in model Forum

Forum.find(:first).creators
# => ActiveRecord::HasManyThroughSourceAssociationNotFoundError: Could not find the source association(s) :creator or :creators in model Topic.  Try 'has_many :creators, :through => :topics, :source => <name>'.  Is it one of :posts or :user?

Are the error messages helpful? I sure think so. But, do we really need all those exception classes? Sure, it’ll keep the error messages DRY.

associations.rb 2014 lib
Uploaded with plasq’s Skitch!

Okay, maybe not. Is it sufficient to have a single ActiveRecordError class (or even a more specific ActiveRecord::AssociationsError)? I could definitely do something like this:


raise ActiveRecord::AssociationsError.new(:has_many, :through_association_not_found, model, reflection)

Whichever way’s the best, I really don’t think it’s good enough validation to miss out on the feature. I can point to a few other more complex areas of the associations code (the crazy eager joins code is why I personally haven’t used :include in any of my apps in over a year).

3 comments

previously

[?]
ActiveReload: the web needs ninjas