1

So, For the sake of performance, I'm using database sessions. I figure that while the sessions are server side, I might as well store commonly accessed objects in the session. So, I'm storing serialized versions of the current_user, current_account, and the current_user's permissions.

The User model handels a lot of the permissions methods (things like user.can_do_whatever), but since i'm trying to be more efficient, and store commonly accessed things in the session (this allows for far fewer DB accesses), does it make sense / break any design standards to (upon each request) store the session in an instance variable in the current_user ?

As of right now, I can't think of any alternatives.

NullVoxPopuli
  • 61,906
  • 73
  • 206
  • 352
  • I've heard you're not supposed to do this (storing objects in the session), but I can't remember what the rationale was (besides the obvious "things getting out of sync" problems, which should be easy enough to deal with if you're careful). I'll see if I can find that reference again... – Xavier Holt Mar 22 '12 at 19:06
  • well, the things accessed from current_user wouldn't matter too much if they got out of sync, cause the only attributes that I'm using from current user are the id, role, and permissions groups. So, if those things change, is it bad to ask them to re-login? =\ – NullVoxPopuli Mar 22 '12 at 19:17
  • maybe, I could just throw some ifs in my users_controller's update method checking for the fields that would require re-login, and then just update the session data – NullVoxPopuli Mar 22 '12 at 19:30

2 Answers2

3

ROR application have by default a RESTful design. One rules of REST is stateless. that mean each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.

If you have trouble with Database performance, use a cache system like memcached wich is already integrated in rails (Caching with Rails).

Vodun
  • 1,377
  • 1
  • 10
  • 12
1

I found a couple of references warning against storing non-primitive data types in the session, but they were all just warnings, and boiled down to: Storing complex objects is "Expecially discouraged" [sic], but if you decide you need to... well, just be careful.

Anyway, I'm kinda taken by the idea of having the users table double as the sessions table, but serialization still seems a bit sketchy. If you're just trying to cut down the number of DB requests, what about storing IDs and using :joins when looking up your user (might require a bit of hackery to get that worked into the default session loading). That avoids synchronization problems and serialization sketchiness, and still only generates a single DB query. Just make sure to use :joins and not :include, as the latter generates a query for each table.

Hope that helps!

Community
  • 1
  • 1
Xavier Holt
  • 14,471
  • 4
  • 43
  • 56
  • well, the sessions aren't stored in the users table. There is a sessions table. I'll def read those references though. – NullVoxPopuli Mar 22 '12 at 19:53
  • @TheLindyHop - Okay - good. 'Cause then I thought about it some more, and started to see all sorts of complications with that idea... I was just about to post an "But wait!" edit, actually. Cheers! – Xavier Holt Mar 22 '12 at 19:55