Friday, May 27, 2011

Madeleine with Rails

I've been recently researching a topic that I was lucky to use 10 years ago - prevalence. Back then I used it with Java. The system still works fine with Prevayler (the prevalence tool for Java).

Nowadays I use Ruby on Rails and whenever I deal with ActiveRecord (which overall is fine...) I miss the old days of Prevayler, where you can use pure objects.

Three years ago I did some initial research at the RailsCamp UK. You can some of the results at this presentation:
http://www.slideshare.net/andrzejkrzywda/madeleine-on-rails-presentation


The results were not positive, mainly due to the one process limitation of madeleine and because of the problems with integrating the madeleine object with the Rails ecosystem.

Now, 3 years later, a few things have improved. There are solid Rails servers which can run with threads (Thin) and Ruby 1.9 solves the threading problems that Ruby 1.8 has. Also, Rails now provides ActiveModel which makes integrating non-AR objects much easier.

I decided that it may be the time to try it again. First results are promising, I was able to rewrite a small part of my side project (search) with the madeleine approach and it seems to work fine (even with the AR objects coexisting in the same app).

I published the madeleine source code to Github (copied from RubyForge) and I applied some small changes to make it work with Ruby 1.9
https://github.com/andrzejkrzywda/madeleine

You can also read more about the prevalence concept at the Prevayler website, most of the things should apply to madeleine:
http://prevayler.org/

Below you will find "slides" from my talk at Poznan Ruby User Group which describe the approach. Let me know if this topic sounds interesting to you. Soon I'm going to post more about it along with some code examples.



Madeleine - Prevayler for Ruby

  • Objects in memory, no db
  • Science-fiction
  • It probably doesn't work, I don't know the reason yet.


Instiki

  • The first public Rails project used Madeleine.
  • DHH almost made it the default persistence for Rails (back in 2004)



Java with Prevayler, 2001 - 2011


  • Work Service - big recruitment agency in Poland
  • main system
  • ORM nightmare
  • 10 years ago and still running
  • Missing the good things...
  • No db.



Objects in memory

  • Snapshots every x minutes (serialization)
  • Changes are serialized



Happy scenario:

  • System works
  • Snapshot is taken when server is stopped
  • Server starts - objects are 
  • deserialized from the snapshot



Unhappy scenario

  • System works
  • Power goes down
  • Server starts - objects are deserialized 
  • from the last snapshot
  • Commands objecs are deserialized and applied
  • We have the system in the same state as before



What is good about it?

  • No ORM, sql, nosql
  • Pure objects
  • No queries - ask objects, methods
  • Very fast - everything in memory
  • Fast development.



What is bad about it?

  • No one uses it.
  • New way of thinking...
  • No data access outside of your application
  • unless you create an API


Single process with threads

  • (Thin)
  • ruby 1.9 only (thread-safe)
  • hard to scale



Lots of default Rails things won't work

  • gems (will_paginate) EDIT: will_paginate can work with arrays, so everything should be fine.
  • everything that depends 
  • on ActiveRecord won't work.
  • ActiveModel helps a lot 
  • (views, validations etc)



One process. Only one command at a time.

  • DateTime.now problem
  • Clock object provided



Migrations mean something different now

  • (pure Ruby code)
  • Refactoring - remember about snapshots.


Thanks for reading!

If you read this far you should Follow andrzejkrzywda on Twitter and subscribe to my RSS

1 comment:

poulwiel said...

Well, well, well - You made IT! Hurray! One side note, DateTime.now is not a problem it's just a rule that You have to follow "all my code is deterministic under all conditions" so in other words no DateTime.now inside a command, a command has to be given a time.