I have a few questions about how well RoR performs under various
'irregular' circumstances. First, how quickly does rails work when
there are potentially lots of embedded ruby expressions (hundreds) per
page? Also, how well does ruby do when there are perhaps hundreds of
database reads per page?

In the app I am designing, there would be a list of messages (let's
say 50 per page in this example, but it might be more.) Each message
could have 0 from a group of several 'tags' applied (funny, serious,
sad, happy, etc...) and I want to to show these tag counts next to the
subject line of the message (only if they are > 0.) This means one of
two things has to happen: I either have to add an integer column to
the messages table for every one of the tag categories (the number of
categories is likely to grow up to 30+.) Or I have to add a table for
these count numbers and do a separate activerecord lookup for each one
of the categories for each of the messages on the page (which really
adds up!)

To give you an example, here's how one message might look:

* Hey Guys, I'm trying Ruby on Rails (Happy x3) (Funny x5) (Geeky x10)


What is the best way to model this for the best performance? Remember
that there could be dozens of other tags that are not displayed
(because they are 0, or for other reasons.)

Is there any way to store a hash (or, if no other way an array of key
value pairs) in an active record class?

Many thanks for any advice you can give.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.

Search Discussions

  • Jeffrey L. Taylor at Nov 25, 2011 at 5:58 pm

    Quoting Andrew Brown <andrewrbrown1@gmail.com>:
    I have a few questions about how well RoR performs under various
    'irregular' circumstances. First, how quickly does rails work when
    there are potentially lots of embedded ruby expressions (hundreds) per
    page? Also, how well does ruby do when there are perhaps hundreds of
    database reads per page?
    Use fragment caching so messages are rendered only when they change. See
    Railscasts #90, http://railscasts.com/episodes/90-fragment-caching

    HTH,
    Jeffrey

    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Andrew Brown at Nov 26, 2011 at 4:26 am
    This looks like the right path I need to go down. Might I add an
    additional resource that helps with the caching needs:
    http://guides.rubyonrails.org/caching_with_rails.html

    However, I have another question about how the caching actually
    works. Does it cache the html output of the fragment it surrounds and
    just serve that up to anyone who requests that fragment each time? If
    so, is it possible to cache an ActiveRecord object and then render it
    in a different way depending on the user who is currently logged in?
    For instance, every user would key off the same cached copy of the
    result (until the row changed) but it would be rendered differently
    depending on various conditions. Can Rails' caching accomplish
    something like this?
    On Nov 25, 10:57 am, "Jeffrey L. Taylor" wrote:
    Quoting Andrew Brown <andrewrbro...@gmail.com>:
    I have a few questions about how well RoR performs under various
    'irregular' circumstances.  First, how quickly does rails work when
    there are potentially lots of embedded ruby expressions (hundreds) per
    page?  Also, how well does ruby do when there are perhaps hundreds of
    database reads per page?
    Use fragment caching so messages are rendered only when they change.  See
    Railscasts #90,http://railscasts.com/episodes/90-fragment-caching

    HTH,
    Jeffrey
    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Walter Lee Davis at Nov 28, 2011 at 2:25 am

    On Nov 25, 2011, at 11:26 PM, Andrew Brown wrote:

    This looks like the right path I need to go down. Might I add an
    additional resource that helps with the caching needs:
    http://guides.rubyonrails.org/caching_with_rails.html

    However, I have another question about how the caching actually
    works. Does it cache the html output of the fragment it surrounds and
    just serve that up to anyone who requests that fragment each time? If
    so, is it possible to cache an ActiveRecord object and then render it
    in a different way depending on the user who is currently logged in?
    For instance, every user would key off the same cached copy of the
    result (until the row changed) but it would be rendered differently
    depending on various conditions. Can Rails' caching accomplish
    something like this?
    Yes. Read the Rails Guide on caching, there's a section labeled Action Caching, which can do what you want.

    Walter
    On Nov 25, 10:57 am, "Jeffrey L. Taylor" wrote:
    Quoting Andrew Brown <andrewrbro...@gmail.com>:
    I have a few questions about how well RoR performs under various
    'irregular' circumstances. First, how quickly does rails work when
    there are potentially lots of embedded ruby expressions (hundreds) per
    page? Also, how well does ruby do when there are perhaps hundreds of
    database reads per page?
    Use fragment caching so messages are rendered only when they change. See
    Railscasts #90,http://railscasts.com/episodes/90-fragment-caching

    HTH,
    Jeffrey
    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprubyonrails-talk @
categoriesrubyonrails
postedNov 25, '11 at 5:20p
activeNov 28, '11 at 2:25a
posts4
users3
websiterubyonrails.org
irc#RubyOnRails

People

Translate

site design / logo © 2021 Grokbase