I have a few models that have “statuses”.
These statuses are currently stored in a database table.
Examples:
id: 1
status: Awaiting Review
id: 2
status: Development
id: 3
status: Production
etc etc.
This data doesn’t really need to be in a database since it probably
won’t change too often. I was wondering, can I have a status model that
doesn’t pull it’s data from a database?
I’ve googled but have had no luck.
Thanks!
Dave
Dave,
I’d be interested in hearing from other folks as well on how they
handle this issue. In the past, I didn’t create a model, but just
documented in the model of the class that has the id (in your case
whatever has the status attribute). So at the top of the model, I
just made a little table showing me the statuses.
If you wanted to be able to programatically be able to access those
statuses, you could create a method that is just a case statement with
each of your id’s. The method could be on a specific object or maybe
at the application level if you uses statuses in multiple places.
What do other people do in these cases? You would hate to hit the
database for something like this…
Thanks,
Tom
On Aug 9, 4:05 pm, Dave C. [email protected]
TomRossi7 wrote:
If you wanted to be able to programatically be able to access those
statuses, you could create a method that is just a case statement with
each of your id’s.
I guess I could create a helper method to do that as well since multiple
models would be referencing this data, then return a value with a case
statement.
Just seems like the data belongs in it’s own model for some reason.
What do other people do in these cases? You would hate to hit the
database for something like this…
Exactly.
Thanks Tom!
app/models/status.rb
class Status
AwaitingReview = 1
Development = 2
Production = 3
end
Nothing in Rails is forcing you to use ActiveRecord::Base as the parent
of
your models. Of course you can do this as methods if you needed, but as
you
said the information won’t change, constants seems like a good fit.
Jason
Jason R. wrote:
Nothing in Rails is forcing you to use ActiveRecord::Base as the parent
of
your models.
Yep, I could do that to. Thanks.
What I’d love to keep though is the automatic association that
activerecord provides, just without the trip to the DB. So, keep the
has_one belongs_to association… Was just wondering if that’s possible.
Dave C. wrote:
What I’d love to keep though is the automatic association that
activerecord provides, just without the trip to the DB. So, keep the
has_one belongs_to association… Was just wondering if that’s possible.
I don’t know if this is exactly what you meant, but I’m working on a
similar problem, and the answer seems to be working pretty well right
now. I have an antique “crashes” datatable with about 30 “flag” fields,
where a “3” in the “location” field means “On Shoulder” and a “1” means
“In Roadway”, etc. Well, like I said, there are about 30 fields like
that, each with its own set of flags.
To make them “human maintainable,” the Columbus Ruby Brigade came up
with this just yesterday:
http://groups.google.com/group/columbusrb/browse_frm/thread/550d2dd0d69b637c
which is a “facade_” prefix for the flag fields. So, if you send
crash.location, you get back a “3”, and if you send
facade_crash_location, you get back “On Shoulder.” If you send
facade_crash_location=“In Roadway,” it sets the “location” value to a
“1”. I.e., you can round-trip via the direct call or the facade call,
whichever is convenient. If you call a “facade_” field which doesn’t
have any flags set, it just returns the value in the field without any
whining.
The model also exposes its flags so you can use them in
“collection_select”, etc. – although I didn’t get a chance to try that
yesterday. The flag’s values are stored in a YAML file, so they’re easy
to edit if needed. I don’t know if this is exactly what you need, but
perhaps it’s close?
Ron