Meta Bates

So a lot has been made in the last few days about my decision to drop ActiveRecord’s native support in Mack. People have asked why can’t I keep what I already have in regards to support for ActiveRecord, and why can’t I support Sequel. So, I’ve decided to compromise.

In the next version of Mack, which should be out in the next day or two, I’ve broken out support for ActiveRecord and DataMapper into their own gems, http://github.com/markbates/mack-orm/tree/master. That means you’ll be able to still use ActiveRecord, if you want. The default ORM, however, will be DataMapper. That’s what you’ll get out of the box with Mack.

Now, keeping with my original post, I’ll be actively maintaining the mack-data_mapper gem, and when I can I’ll make similar changes to the mack-active_record, but I’m not promising anything. Now the good thing here is that since the repos for these gems are on GitHub, anyone can contribute changes/additions to them. I’ve even put a stub in there for Sequel support, that’s definitely something someone else will have to support.

This also has a nice advantage in keeping the Mack core clean and simple. Hopefully this will all lead to faster development time turn around for Mack.

It’s also worth noting that when I talk about ‘native’ support, all I mean is some Rake tasks and some generators. There’s nothing stopping anyone from using ANY ORM with Mack. You could even create your own, if you really wanted to.

Here’s to hoping this makes everyone happy!

Well, here it is! The release you all were waiting for, the one that finally gives migration support to Mack! That’s right, now whether you use ActiveRecord or DataMapper, you can use the familiar rake task ‘db:migrate’ to run your migrations. Yippie! The scaffold generator will also generate a migration for you, assuming you have ORM support enabled.

There’s still some work to go on this, like the ability to pass in command line args to the task to build the full migration for you, but it’s a start! It’s now pretty easy to get your app going.

Also in this release is a rewrite of the distributed routing functionality. It’s now been rewritten to use Rinda. This is going to be the standard for all the distributed functionality that will be coming Mack over the next couple of months. As more functionality lke this is developed, the more it will be wrapped in nice, easy to use APIs.

There’s also been some tidying up here in there in the code tree. For example, new applications don’t get generated with a boot.rb file. Looking at it, there’s really no need for it, since everything is done with Rake tasks.

Overall, I’m very happy with the release, and I feel that this release definitely makes Mack a VERY useable framework because of the migration support. Enjoy!

Changelog:

• Removed boot.rb file. It was unnecessary.
• When a new Mack application is generated the Rakefile that gets generated is stamped with the Mack gem version used to create it. This ties the project to that gem. This can, of course, be upgraded as new Mack gems come out, but it’s a good way of tying your app to a specific revision of Mack.
• Added support for migrations for both ActiveRecord and DataMapper. DataMapper migration support requires DataMapper 0.3.0 gem. Please keep in mind, though, that DataMapper 0.3.0 has a serious bug in it, which may prevent you from using it. Please see http://www.mackframework.com/2008/04/09/horrible-bug-in-datamapper-030/ for more information.
• Rewrote distributed routing support to use Rinda inside of plain old DRb. This makes for an almost zero configuration usage.
• Added: mack_ring_server binary to start a Rinda ring server for use with distributed routing.
• Sqlite3 is now the default database for Mack applications configured with ORM support.
• Added a test helper method, rake_task, to aid in the testing of Rake tasks.
• Added: rake generate:migration name=<migration_name>
• Added: rake db:migrate
• Added: rake db:abort_if_pending_migrations
• Added: rake db:rollback
• Added: rake db:version
• Added: rake mack:ring_server:start
• Added: rake mack:ring_server:stop
• Added: rake mack:ring_server:restart
• Added: rake mack:ring_server:services:list
• gem: application_configuration 1.2.2
• gem: daemons 1.0.10

Now that I’m back on track with DataMapper, I’ve got migration support for both it and ActiveRecord just about done. In addition to the actual rake task, db:migrate (btw), I had to set up a good way to test rake tasks, something I’ll share at a later date, but needless to say it’s included with Mack. I also had to deal with the pain in the ass-ness of dealing with two VERY different ORMs, in the same test system! Let me tell you, that sucked!

Good news is that things seem to be working, at least going in the ‘up’ direction anyway. I still need to write the ‘down’ direction revert stuff. Hopefully, that shouldn’t take too long now that I have a good way of testing the task and the migration stuff.

Unfortunately, I feel as though as soon as I release this stuff, which should be by the end of this weekend, DataMapper 0.9.0 will be out, and I’ll have to re-write most of the DataMapper stuff because the API is changing so radically. I guess I’ll just have to deal with that when the time comes.

In the meantime I’ll let y’all know when migrations are done and out there in the wild.

After two years of developing Menderchuck using Rails, I sat down with the VP of Development and the Director of Development and we took at a look at what the future of the company. We reviewed some of the stuff the business would like to build and where the CEO saw the company headed, and we looked at the technologies we were using and determined that it was time to investigate alternatives.

The first things to come under the microscope were Rails/Mongrel. As previously stated we found Rails to be a bit too opinionated for our use. One of the big jokes within the dev team was that I was basically rewriting Rails one section at a time. As sad as that joke is, it’s partially true.

I started to investigate other frameworks, particularly Merb and Ramaze, both of which are great frameworks. Both are lightweight and fast, and are a great alternative to Rails. But, they both didn’t quite offer what Menderchuck needed to grow into the future.

Menderchuck needed a platform that was fast and scalable. We needed something that would allow us to be a portal application. We needed something that was easy to deploy. We wanted to be able to build/deploy separate applications and have them ‘automagically’ linked together. And most importantly we needed something very configurable, and less opinionated.

In the search for a framework utopia, I came across two technologies I really fell in love with, Rack and Thin.

(More to come…)