In preparing for battle, I have always found that plans are useless, but planning indispensable
The first intercollegiate football game was played in New Brunswick, New Jersey (Rutgers College played Princeton)
- Blog Categories
- Software (29)
- Music (11)
- Life (4)
- Cars (3)
- Randomness (4)
-
Model Versioning In Rails
Versioned data is common to many applications. Consider the case of an online store selling products. A simplified view of the product data might consist of the upc, description, volume, and price. Let's suppose a customer purchases a product on September 12th for a certain amount, then we update the product info to reflect a price increase. If we dont keep a snapshot of the product data before the price increase, the customer's order history will be generated from the new product data instead of the product data at the time of purchase.
Ok, so we basically need a parallel product table to append a new entry to each time a product's data is updated. The main product table will always hold the current data. In Rails, this means that we need to somehow hijack the ActiveRecord call flow and intercept any updates to all product instances, append a new entry to the versioned table with a timestamp, and then somehow tell active record to resume its updating of the original product, making note of the version that was just appended. That sucks. I thought about using an observer, or maybe a callback...but there is definitely a better way - the acts_as_versioned plugin.
Let's go through the basic setup to getting this working.
-
Install the plugin:
prompt$ gem install acts_as_versioned
-
update the product model to use the plugin:
class Product < ActiveRecord::Base
acts_as_versioned
...
end -
Create your database tables.
Class CreateProducts < ActiveRecord::Migration
def self.up
create_table :products do |t|
t.column :version, :integer
t.column :upc, :integer
t.column :description, :string, :null => false
t.column :volume, :float, :null => false
t.column :price, :decimal
end
Product.create_versioned_table
end
def self.down
drop_table :products
Product.drop_versioned_table
end
end
Note that we are required here to add a version column to the main product table that will automatically be updated with the current version on each update (sequential, starting at 1.) You can use the
version_columnoption to theacts_as_versioneddeclaration if you would like to rename the column. Also note that we use thecreate_versioned_tableclass method that was added to the Product class with theacts_as_versioneddeclaration. This method will automatically create a product_versions table with a product_id foreign key column, an updated_at datetime column, a version column, and a colum for each column in the products table. Thedrop_versioned_tableclass method will drop the table generated by the corresponding call tocreate_versioned_table.
Now you can start adding products and updating them, and you will see the versions magically appear in the product_versions table. There are a couple of problems here though. First of all, we are versioning all of the columns from the original model. In our example here, once a product is created, I know that the UPC cannot be changed, therefore there is no point in wasting a column for every version of every product. It turns out that the plugin will refer to the
non_versioned_fieldsclass method to determine which columns to generate in the migration and which columns in the versioned table (and corresponding object methods) to populate on each update. If we add our own columns to the array returned bynon_versioned_fields, we can exclude certain columns from being versioned:class Product < ActiveRecord::Base
acts_as_versioned
non_versioned_fields.push "upc"
end
Note here that you pushing symbols onto the array will not work, you must use strings. I have to admit that I'm a bit skeptical of the correctness of my implementation here, so please let me know if something seems a bit funky with the column exclusions (or anything else for that matter.)
The other problem is that by default, a new version will be appended to the versions table on every update. This means that if you change nothing on your product object and call update, a new version will be added. We can correct this using the :if_changed option to the original acts_as-versioned declaration.
class Product < ActiveRecord::Base
acts_as_versioned :if_changed => [:description, :volume, :price]
...
endThis means that a new version will not be appended unless the description, volume, or price column has changed. The plugin also supports more complex version checks with
:ifandversion_condition_met?.I have to say that I'm pretty excited to start using this in some of my projects. At first I was a bit worried about the fact that the most current realease starts with a 0, but hey - its probably a hell of a lot more solid than anything I could come up with :)
Tuesday, September 12, 2006 10:06 PM EDT6 Comments Filed in: Software -
Install the plugin:
-
Value Object Aggregation In Rails
Aggregation is an important concept that should arguably be applied to any domain of reasonable complexity. While this statement is certainly open for discussion, I feel that it's important to study what aggregation is and discover the benefits of making a distinction between true Entities and things that are just Value Objects. An Entity can be defined most simply as something that needs to maintain it's own state, whereas a Value Object is just a certain value (or collection of values) that has no state. Consider the following portion of a domain model:
In the example shown, both distributor and customer have an address. I would consider the address to be a Value Object since it has no state. Please realize that there may be some application domains where an address should be modeled as an entity, I just don't feel that this domain is one of them. Another way to think about this is that the address has no identity outside of the context of either a distributor or a customer. Therefore, we refer to distributor and customer as Root Entities. A value object should not be accessible without first going through a root entity. So, theoretically speaking, you should never be able to write the following code:
address = Address.new
address.save
The problem with the above code is that it refers to the address as it's own entity, which we said is probably not a good idea. We should only allow access to a value object through an owning entity like so:
address = Address.new
customer = Customer.new(:address => address)
customer.save
The difference here is that we are assigning the address to a customer and then saving the customer. So again, the address only makes sense within the context of a customer (or distributor) object. There is another subtle point going on here. Since an address has no state of its own, we should never be allowed to modify the address object - the address should be Immutable. This means that if the customers address changes, we would need to create a new address object and associate it with the customer and re-save the customer. Calling
customer.address.zip = 08080doesn't make sense (from a pedagogical point of view anyways.)OK, enough theory - lets talk about implementation. Active Record has direct support for aggregation through the use of the
composed_ofkeyword. Lets assume the following migrations are used to create the Customer and Distributor tables:
class CreateCustomers < ActiveRecord::Migration
def self.up
create_table :customers do |t|
t.column :customer_name, :string
t.column :phone_number, :string
t.column :email, :string
t.column :address_1, :string
t.column :address_2, :string
t.column :city, :string
t.column :state, :string, :limit => 2
t.column :zip, :string, :limit => 10
end
end
def self.down
drop_table :customers
end
end
class CreateDistributors < ActiveRecord::Migration
def self.up
create_table :distributors do |t|
t.column :distributor_name, :string
t.column :distributor_region, :string
t.column :phone_number, :string
t.column :email, :string
t.column :address_1, :string
t.column :address_2, :string
t.column :city, :string
t.column :state, :string, :limit => 2
t.column :zip, :string, :limit => 10
end
end
def self.down
drop_table :distributors
end
end
Now, what we'd like to do is abstract the address columns into their own Address class. This will allow us to say things like
customer.address.address_1after Active Record has retrieved a collection of Customer objects for us. To further clarify, the following code should not run once we're done:distributor.address_1. The real benefit here is not just the syntactic sugar of adding 'address' to the reader method, rather we can now implement certain address related functionality (likecalculate_distance,) and have that functionality be shared among multiple root entities of address objects.First, we need to tell the Distributor and Customer classes that they should be composed of an Address:
class Customer < ActiveRecord::Base
composed_of :address,
:class_name => "Address",
:mapping =>
[
[ :address_1, :address_1 ],
[ :address_2, :address_2 ],
[ :city, :city ],
[ :state, :state ],
[ :zip, :zip ]
]
end
class Distributor < ActiveRecord::Base
composed_of :address,
:class_name => "Address",
:mapping =>
[
[ :address_1, :address_1 ],
[ :address_2, :address_2 ],
[ :city, :city ],
[ :state, :state ],
[ :zip, :zip ]
]
end
In the above two class definitions, the mapping and class_name attributes are optional. The class_name attribute isn't needed if the class name is the camel-cased version of the composed_of value. Additionally, the mapping attribute is not needed if each value pair contains identical values (as they do in this case.)
Now we can go ahead and create our Address class:
class Address
attr_reader :address_1, :address_2, :city, :state, :zip
def initialize(address_1, address_2, city, state, zip)
@address_1 = address_1
@address_2 = address_2
@city = city
@state = state
@zip = zip
end
end
Since Address objects will be immutable, we create only attribute reader methods. The attributes can only be set at initialization time. Rails further enforces immutability by freezing the value object once it has been associated with an entity.
So now that I've shown you how to implement such a thing, let's talk about the abundant shortcomings of this.
Duplication:
As you can see, there is a fair amount of duplication going on here. Not only are we re-defining all of the address attributes in each table that will be composed of an address, but we are also duplicating the mapping and class_name values in both the Customer and Distributor classes.
Validation
This is the deal breaker. Value objects in rails are completely dis-associated from ActiveRecord, which means they cannot use the wonderful validation framework provided. To be quite honest, this pisses me off. I believe this will make value objects in rails unusable in all cases where the value objects don't contain reference data. Yes, I'm aware of workarounds for this problem, like tricking the value object into thinking it's being handled by ActiveRecord, but to be honest with you, its not quite worth the hassle. I'd much sooner just make the value object an entity of it's own and lose the theoretical correctness of not maintaining the state of the object. But wait, that would bring up another problem: How do I associate an entity with more than one kind of other entity? The answer lies in one beautiful addition to Rails 1.1: Polymorphic Associations...
Wednesday, September 27, 2006 11:58 AM EDT4 Comments Filed in: Software