Browse the Ruby on Rails Community.

You are here: Forums Ask a Rails expert Model types/states...

Replytotopic

Model types/states

Posted in Forums : Ask a Rails expert

 
Profile

Authority 37
Posting Rating 84
Sign in to rate this post

I’m wondering how other Rails experts handle states and types of model instances. For example: an Address record has a type Home, Work or Other. There are several options for solving this problem:

  1. Create HomeAddress, WorkAddress and OtherAddress models and use single-table inheritance.
  2. Create an AddressType model and associate it with Address records
  3. Store a string representation of the type in the Address record
  4. Store an integer representation of the type in the Address record

In my opinion, option 1. and 2. are a bit overkill. Creating more models for only three types is not very nice and can lower the overview of the models in a project.

Storing a string representation is an option, but also doesn’t have my preference. The string representation is often localized for display in the views and it takes a lot of space in the database.

I’m currently using the last option, combined with a constant Hash in an initializer:

ADDRESS_TYPES = {
    1 => "Work",
    2 => "Home",
    3 => "Other" 
}

When storing a new Address record the integer representing the state is stored in the database. Displaying the description of the state is done with ADDRESS_TYPES[address_instance.type_id]. Main disadvantage of this technique is the use of integers in the code, for example when selecting all work addresses:

Address.find(:all, :conditions => ["type_id = ?", 1])

The code isn’t readable like this and you force developers to lookup the meaning of the ‘1’ in the hash.

So my question is: how would you solve this?

Note: the Address model is just an example, there are many more examples of types and/or states that should be usable in views, readable in the code and easy to store in the database.

Thanks!

 
Matthias

Authority 37
Posting Rating 1
Sign in to rate this post

You could set a constant for each type:

WORK = 1
HOME = 2
OTHER = 3

But i would not do that and instead revisit my domain model.
Is ‘work’ really a property of an address?
I think this kind of type is more likely the property of a
relation: A person can have a workaddress but the address itself only specifies a location.
I would rather have an association class between
Address and whatever model stands in relation to Address and let this
association know what the relation between the model (eg Person) and the Address is.

Matthias

 
Profile

Authority 37
Posting Rating 84
Sign in to rate this post

I absolutely think your solution works for the Address case, but as I stated before: this isn’t specific about the address case. Although creating a join model for this relation might be a bit overkill because one address is not likely to be used more than once and even when it is, you don’t let other users choose from a list of already entered addresses.

Working with the constants for each type doesn’t make it more clear in my opinion. Are the three constants the only one that can be used as an address type? What about other constants? This coding standard doesn’t say anything about the set from which a type should be chosen.

Working with the constants is absolutely better compared to the integers.

 
Me

Authority 37
Posting Rating 100
Sign in to rate this post

I’d probably have a second table address_types where I store the name of the address type (“Work”, “Home”, “Holiday”, whatever). This way everything stays clear and is extendable because users can optionally add new types if need be.
Maybe not the best solution but definitely an option …

 
Profile

Authority 12
Posting Rating 96
Sign in to rate this post

To go on from Clemens’ point (using an AddressType model), you could also use the caches_constants plugin (I think I mentioned it in this forum a while ago). http://trac.extendviget.com/lab/wiki/CachesConstants . I’m using similar code in one of my models.

 
Profile

Authority 37
Posting Rating 84
Sign in to rate this post

Thanks for the link Jon, didn’t know the plugin, but seems really useful for this situation. I agree with Clemens that taking changes in the types into account is also important.

Replytotopic

Other Recent Topics

Ask a Rails expert : Sanitizing html

Ask a Rails expert : First post, requesting sage perspective

Ask a Rails expert : How to use mephisto

Ask a Rails expert : How to use mephisto

Ask a Rails expert : will_paginate customization problem

Ask a Rails expert : BackgroundRB still wants 'development' environment...?

Ask a Rails expert : activescaffold, sql exception

Ask a Rails expert : Passing non-english chars in query string

Ask a Rails expert : Rails and 2D barcodes

Ask a Rails expert : apache giving proxy error

Formatting Help
  • *bold*       _italics_      
    bq. (quotes)
  • "DSC":http://www.dsc.net
  • * or # (lists)
or cancel