Forum: Ruby on Rails Storing ActiveRecords in the Session

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
A6d9ea53328a9e547cd10d4c30586bdb?d=identicon&s=25 Robert Head (roberthead)
on 2007-01-26 00:31
Is there a secret to successfully storing ActiveRecords in the Session
(which is being stored in the DB) without getting marshalling
exceptions?
538fa89682589ea480d524756fa0841d?d=identicon&s=25 Peter Ertl (Guest)
on 2007-01-26 12:33
(Received via mailing list)
just store the primary key of the record... that's usually much better

2007/1/26, Robert Head <rails-mailing-list@andreas-s.net>:
95ac4011d0e657db0c3be18000eaeb36?d=identicon&s=25 Robert Head (Guest)
on 2007-01-26 22:57
Peter Ertl wrote:
> just store the primary key of the record... that's usually much better
>

Sure, but then I have to hit the DB *every time* I use it, no?
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2007-01-26 23:05
(Received via mailing list)
On Jan 26, 2007, at 1:57 PM, Robert Head wrote:

> Peter Ertl wrote:
>> just store the primary key of the record... that's usually much
>> better
>
> Sure, but then I have to hit the DB *every time* I use it, no?

No, it's relatively easy to make sure the 'penalty' is once per page
that uses it.

The session is likely a DB hit in any case (ActiveRecordStore), and
if you put an
entire AR model in it, it makes this session DB hit a monster each
and every page.

Storing the ID makes sure that your AR model isn't stale, too.

--
-- Tom Mornini, CTO
-- Engine Yard, Ruby on Rails Hosting
-- Reliability, Ease of Use, Scalability
-- (866) 518-YARD (9273)
95ac4011d0e657db0c3be18000eaeb36?d=identicon&s=25 Robert Head (Guest)
on 2007-01-31 21:28
Tom Mornini wrote:
> On Jan 26, 2007, at 1:57 PM, Robert Head wrote:
>
>> Peter Ertl wrote:
>>> just store the primary key of the record... that's usually much
>>> better
>>
>> Sure, but then I have to hit the DB *every time* I use it, no?
>
> No, it's relatively easy to make sure the 'penalty' is once per page
> that uses it.

OK, exactly.  So, what is the "relatively easy" way to make sure the
object is only loaded once per page?

- Still perplexed
6076c22b65b36f5d75c30bdcfb2fda85?d=identicon&s=25 Ezra Zygmuntowicz (Guest)
on 2007-01-31 22:52
(Received via mailing list)
On Jan 31, 2007, at 12:28 PM, Robert Head wrote:

>> No, it's relatively easy to make sure the 'penalty' is once per page
>> that uses it.
>
> OK, exactly.  So, what is the "relatively easy" way to make sure the
> object is only loaded once per page?
>
> - Still perplexed
>
> --
> Posted via http://www.ruby-forum.com/.


   def current_user
     @current_user ||= session[:user_id] ? User.find_by_id(session
[:user_id]) : nil
   end

This will cache the the user in @current_user so you can call
current_user multiple times during a request and it will only hit the
db once.

Cheers-
-- Ezra Zygmuntowicz
-- Lead Rails Evangelist
-- ez@engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)
Ccf272215de791321c8bdee9684ce447?d=identicon&s=25 surf (Guest)
on 2007-01-31 23:01
(Received via mailing list)
On Jan 31, 5:51 pm, Ezra Zygmuntowicz <ezmob...@gmail.com> wrote:
> >>>> just store the primary key of the record... that's usually much
> > - Still perplexed
> current_user multiple times during a request and it will only hit the
> db once.
>


 This reminds me of something similar, suppose on sign up or in some
form the user has to fill in 20 or 30 fields and send them to the
server. The server validates them and creates a record on the
database. However, suppose that there is some complex logic that needs
to validate the form data beyond some simple stuff you could do
through javascript, perhaps you could do some sort of AJAX thing, but
the other possibility seems to be to store the form fields in the
session because the record may not get created on the database if
there is a problem, but you don't want the user to have to fill the
fields all in again. I did it that way previously before I had done
much AJAX, but then I realized the session uses alot of space on the
file system.
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2007-01-31 23:30
(Received via mailing list)
surf wrote:

> much AJAX, but then I realized the session uses alot of space on the
> file system.

I would try this:

 - database table with a 'committed' boolean
 - uncommitted records are disposable
 - committed records are transactable
 - build a Model out of the table with no validators
 - inherit a class, Q, from that Model & add validators
 - paint the form with the Model & submit it
 - to commit, copy the attributes into an instance of Q
 - set the committed bit, and try to save

I don't know if each detail there would work, or cause problems. But in
general the point of OO is to abstract the thing that varies, so if the
validators are the issue you should arrange to move them out of the way,
instead of working around them. A user with a partly committed form
should
be able to return to it.

--
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
A6d9ea53328a9e547cd10d4c30586bdb?d=identicon&s=25 Robert Head (roberthead)
on 2007-02-01 01:10
Ezra Zygmuntowicz wrote:
>
>    def current_user
>      @current_user ||= session[:user_id] ? User.find_by_id(session
> [:user_id]) : nil
>    end
>
> This will cache the the user in @current_user so you can call
> current_user multiple times during a request and it will only hit the
> db once.
>
> -- Ezra Zygmuntowicz

I'll try that again, but, IIRC, the last time I tried it, I was getting
marshaling problems when saving the object for some reason.

Thanks.
6076c22b65b36f5d75c30bdcfb2fda85?d=identicon&s=25 Ezra Zygmuntowicz (Guest)
on 2007-02-01 01:30
(Received via mailing list)
On Jan 31, 2007, at 4:10 PM, Robert Head wrote:

>> db once.
>>
>> -- Ezra Zygmuntowicz
>
> I'll try that again, but, IIRC, the last time I tried it, I was
> getting
> marshaling problems when saving the object for some reason.
>
> Thanks.
>

  Don't save the whole object thats the entire point. Just save the
objects id in the session. That method will use the id to do a db
lookup and then cache the results.


-- Ezra Zygmuntowicz
-- Lead Rails Evangelist
-- ez@engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)
A6d9ea53328a9e547cd10d4c30586bdb?d=identicon&s=25 Robert Head (roberthead)
on 2007-02-01 14:14
Ezra Zygmuntowicz wrote:

>   Don't save the whole object thats the entire point. Just save the
> objects id in the session. That method will use the id to do a db
> lookup and then cache the results.

To clarify, the question is what class your suggested code lives in.

When I created instance variables (where you are caching the object) in
a model class, saving the record generated marshaling exceptions.

An example like your current_user method looks like it would probably
live in a controller or helper and therefore not be saved and not create
a problem.

Should I be able to drop ActiveRecord objects into instance variables in
another ActiveRecord instance without getting marshaling problems?  I
should test again, but that is contrary to my experience.
C381828d1907912eab30cbe38d5ea245?d=identicon&s=25 unknown (Guest)
on 2007-02-01 14:36
(Received via mailing list)
Take a look at  object_id_session plugin from Yurii Rashkovskii:

http://rashkovskii.com/articles/2007/1/2/object_id_session

--
AnĂ­bal Rojas
http://www.rubycorner.com
http://www.hasmanydevelopers.com
This topic is locked and can not be replied to.