Rails - Jan 2006 - NoobyQ: how to work with a table of static lookup data??

Hello out there!

Nooby question: What''s the "Rails" way to work with tables of
relatively
static lookup data?

Objectively (I''m thinking); I don''t want to hit the DB each
time, so for
each lookup table, initialize a globally available hash with lable/value 
pairs...

Am I on the right track?

How would you do this kind of thing in Rails?

Thanks!


-- 
Posted via http://www.ruby-forum.com/.

Randy,

Being a newby I see some possibilities. You could set up caching (I''ve
read
that somewhere). Or you could put it in an array (in a controller if
it''s not
to big) or as a flat text file.
I think it depends on in what format you get the information in the first 
place, and how often it''s updated

Ik hope (wonder if) it helps.

Regards,

Gerard.


On Monday 02 January 2006 06:31, randy marmer tried to type something
like:
> Hello out there!
>
> Nooby question: What''s the "Rails" way to work with
tables of relatively
> static lookup data?
>
> Objectively (I''m thinking); I don''t want to hit the DB
each time, so for
> each lookup table, initialize a globally available hash with lable/value
> pairs...
>
> Am I on the right track?
>
> How would you do this kind of thing in Rails?
>
> Thanks!
-- 
"Who cares if it doesn''t do anything?  It was made with our new
Triple-Iso-Bifurcated-Krypton-Gate-MOS process ..."

My $Grtz =~ Gerard;
~
:wq!

On Mon, Jan 02, 2006 at 06:31:55AM +0100, randy marmer wrote:
} Nooby question: What''s the "Rails" way to work with tables
of relatively
} static lookup data?
} 
} Objectively (I''m thinking); I don''t want to hit the DB each
time, so for
} each lookup table, initialize a globally available hash with lable/value 
} pairs...
} 
} Am I on the right track?
} 
} How would you do this kind of thing in Rails?

Assuming you have your database connections set up properly (in
config/database.yml) you should be able to use the ActiveRecord connection.
Assume that your DB table name is Lookup_Data with Lookup_Key and
Lookup_Value columns:

$lookup_data = {}
ActiveRecord::Base.connection.select_all(''SELECT Lookup_Key,
Lookup_Value
FROM Lookup_Data'').each { |row|
  $lookup_data[row[''lookup_key'']] =
row[''lookup_value'']
}

Note that the capitalization in the row column names may vary depending on
which database driver you are using. I tested this with the PostgreSQL
driver, and it insists on the column names being lowercase.

} Thanks!
--Greg

Gregory Seidman wrote:
> $lookup_data = {}
> ActiveRecord::Base.connection.select_all(''SELECT Lookup_Key, 
> Lookup_Value
> FROM Lookup_Data'').each { |row|
>   $lookup_data[row[''lookup_key'']] =
row[''lookup_value'']
> }

Thanks Greg - & Gerard, thank you too - for responding...

Greg, the approach you suggest seems quite reasonable... But I''m 
wondering where it belongs? The lookup tables that I''m referencing are 
relatively static, so it would not be necessary to load them very often.

Would this type of thing go into the initialize method of the 
application controller? Frankly, I''m still confused about how
it''s Rails
uses the application controller in practice... Would its initialize 
method be called once per session (i.e. per browser)? If so then that 
would seem to be the most logical spot to place this kind of code... ? 
Am I more or less on track or is there a more standard "Rails
approach"
to pull this off?

Thanks again!

-- 
Posted via http://www.ruby-forum.com/.

Randy,

I''m fairly intelligent but a newbie when it comes to ruby on Rails. So
I can
definitely say something from a logical/technical perspective but from the 
ruby side of things not as detailed as greg''s doing.

Nevertheless. I don''t know how much data we''re talking about.
You could
consider trying two out of three, and simply do performance tests. Comparing 
results would definitely bring factors of influence to the surface. DB I/O 
could slow things down. Would (if using a flat file) only the accessed data 
be read in or always the whole file. If you''re discs handle heavy I/O
every
thing permantly in memory could be an option. etc, etc.

If the data is somewhat straight foreward and the queries to access it as 
well, my choice would be a flat file for starters.

If you should have any questions, a will gladly try to answer them.

Regards,

Gerard.

On Monday 02 January 2006 22:47, randy marmer tried to type something
like:
> Hey,
>
> Thanks for your response.
>
> Your 2nd suggestion is the one I was considering &
> consistent with the response from Greg that
> followed...
>
> I''m still uncertain, however, about where it ought to
> go & how it ought to work... I expressed this in my
> response to Greg & I''m hoping that he or some other
> kind soul can set me straight.
>
> Thanks again.
>
> Randy
>
> --- Gerard <mailing@gp-net.nl> wrote:
> > Randy,
> >
> > Being a newby I see some possibilities. You could
> > set up caching (I''ve read
> > that somewhere). Or you could put it in an array (in
> > a controller if it''s not
> > to big) or as a flat text file.
> > I think it depends on in what format you get the
> > information in the first
> > place, and how often it''s updated
> >
> > Ik hope (wonder if) it helps.
> >
> > Regards,
> >
> > Gerard.
> >
> >
> > On Monday 02 January 2006 06:31, randy marmer tried
> >
> > to type something like:
> > > Hello out there!
> > >
> > > Nooby question: What''s the "Rails" way to work
> >
> > with tables of relatively
> >
> > > static lookup data?
> > >
> > > Objectively (I''m thinking); I don''t want to hit
> >
> > the DB each time, so for
> >
> > > each lookup table, initialize a globally available
> >
> > hash with lable/value
> >
> > > pairs...
> > >
> > > Am I on the right track?
> > >
> > > How would you do this kind of thing in Rails?
> > >
> > > Thanks!
> >
> > --
> > "Who cares if it doesn''t do anything?  It was made
> > with our new
> > Triple-Iso-Bifurcated-Krypton-Gate-MOS process ..."
> >
> > My $Grtz =~ Gerard;
> > ~
> >
> > :wq!
>
> __________________________________
> Yahoo! for Good - Make a difference this year.
> http://brand.yahoo.com/cybergivingweek2005/
-- 
"Who cares if it doesn''t do anything?  It was made with our new
Triple-Iso-Bifurcated-Krypton-Gate-MOS process ..."

My $Grtz =~ Gerard;
~
:wq!

Check out

Trevor Squires enumerations plugin

 Features
    Caching
    act_as_enumerated
    has_enumerated


On 1/2/06, Gerard <mailing@gp-net.nl> wrote:
>
> Randy,
>
> I''m fairly intelligent but a newbie when it comes to ruby on
Rails. So I
> can
> definitely say something from a logical/technical perspective but from the
> ruby side of things not as detailed as greg''s doing.
>
> Nevertheless. I don''t know how much data we''re talking
about. You could
> consider trying two out of three, and simply do performance tests.
> Comparing
> results would definitely bring factors of influence to the surface. DB I/O
> could slow things down. Would (if using a flat file) only the accessed
> data
> be read in or always the whole file. If you''re discs handle heavy
I/O
> every
> thing permantly in memory could be an option. etc, etc.
>
> If the data is somewhat straight foreward and the queries to access it as
> well, my choice would be a flat file for starters.
>
> If you should have any questions, a will gladly try to answer them.
>
> Regards,
>
> Gerard.
>
> On Monday 02 January 2006 22:47, randy marmer tried to type something
> like:
> > Hey,
> >
> > Thanks for your response.
> >
> > Your 2nd suggestion is the one I was considering &
> > consistent with the response from Greg that
> > followed...
> >
> > I''m still uncertain, however, about where it ought to
> > go & how it ought to work... I expressed this in my
> > response to Greg & I''m hoping that he or some other
> > kind soul can set me straight.
> >
> > Thanks again.
> >
> > Randy
> >
> > --- Gerard <mailing@gp-net.nl> wrote:
> > > Randy,
> > >
> > > Being a newby I see some possibilities. You could
> > > set up caching (I''ve read
> > > that somewhere). Or you could put it in an array (in
> > > a controller if it''s not
> > > to big) or as a flat text file.
> > > I think it depends on in what format you get the
> > > information in the first
> > > place, and how often it''s updated
> > >
> > > Ik hope (wonder if) it helps.
> > >
> > > Regards,
> > >
> > > Gerard.
> > >
> > >
> > > On Monday 02 January 2006 06:31, randy marmer tried
> > >
> > > to type something like:
> > > > Hello out there!
> > > >
> > > > Nooby question: What''s the "Rails" way to
work
> > >
> > > with tables of relatively
> > >
> > > > static lookup data?
> > > >
> > > > Objectively (I''m thinking); I don''t want
to hit
> > >
> > > the DB each time, so for
> > >
> > > > each lookup table, initialize a globally available
> > >
> > > hash with lable/value
> > >
> > > > pairs...
> > > >
> > > > Am I on the right track?
> > > >
> > > > How would you do this kind of thing in Rails?
> > > >
> > > > Thanks!
> > >
> > > --
> > > "Who cares if it doesn''t do anything?  It was made
> > > with our new
> > > Triple-Iso-Bifurcated-Krypton-Gate-MOS process ..."
> > >
> > > My $Grtz =~ Gerard;
> > > ~
> > >
> > > :wq!
> >
> > __________________________________
> > Yahoo! for Good - Make a difference this year.
> > http://brand.yahoo.com/cybergivingweek2005/
>
> --
> "Who cares if it doesn''t do anything?  It was made with our
new
> Triple-Iso-Bifurcated-Krypton-Gate-MOS process ..."
>
> My $Grtz =~ Gerard;
> ~
> :wq!
>
>
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
First they laugh at you, then they ignore you, then they fight you.
Then you win.
-- Mahatma Karamchand Gandhi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060102/e67fbc02/attachment-0001.html