Opened 8 years ago

Closed 8 years ago

#3776 closed (wontfix)

user sessions

Reported by: upadhyay@… Owned by: nobody
Component: Contrib apps Version: master
Severity: Keywords:
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Django has anonymous sessions, tracked by cookies. The session can not be accessed from a different machine for the same user, which drastically reduces the usefulness of sessions. Another approach to save something persistently for a user it to update the UserProfile model and create a new row for the same, but this will require altering the corresponding table every time we realize we have one more thing to save.

What I am proposing is this: we update the User model, and add a "session_data = models.TextField(_('session data'))" to it. Additionally in User.init we add a "self.session = SessionWrapper('user:%s' % self.id)". We will have to add a .save() method on django.contrib.sessions.middleware.SessionWrapper, and optionally update django.contrib.sessions.middleware.SessionMiddleware.process_response to call request.user.session.save() if request.user.session.modified is true.

Change History (8)

comment:1 follow-up: Changed 8 years ago by Ben Slavin <benjamin.slavin@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

-1 on this.

I don't think sessions are the right approach for this functionality.

I think that if you're looking to persist data, it belongs in a formal model somewhere (perhaps UserProfile, as you mention), not in sessions.

comment:2 Changed 8 years ago by Gary Wilson <gary.wilson@…>

  • Triage Stage changed from Unreviewed to Design decision needed

comment:3 in reply to: ↑ 1 Changed 8 years ago by anonymous

Replying to Ben Slavin <benjamin.slavin@gmail.com>:

I think that if you're looking to persist data, it belongs in a formal model somewhere (perhaps UserProfile, as you mention), not in sessions.

Well think this would be quite convenient. I mean I have like 5 types of messages for my site users, and I want to put a "dont show this type of message again", and this number keeps on changing as we keep on adding minor features. Requiring a model update on each such change is wasteful and error prone process. We are never going to do a query on any of these parameters, and having columns after columns is just not clean. Imagine documenting such 20 bool columns. And many times things change from bool to enum, and sometime to more complicated data structures.

Not having user sessions just limits the number of things you would be willing to store for users, and framework would end up dictating site design.

comment:4 follow-up: Changed 8 years ago by Simon G. <dev@…>

  • Resolution set to invalid
  • Status changed from new to closed

It sounds like you have a design problem - For something like this, I'd go for a model like this:

class Messages(models.Model):
    """ Stores Message Information."""

    MESSAGE_CHOICES = (
        (0, 'Message Type 1'), # or whatever
        (1, 'Message Type 2'),
        (2, 'Message Type 3'),
    )

    user = models.ForeignKey(User, related_name="user_set")
    message_type = models.CharField(maxlength=1, choices=MESSAGE_CHOICES, db_index=True, default=0)
    message = models.TextField()

comment:5 in reply to: ↑ 4 Changed 8 years ago by anonymous

Replying to Simon G. <dev@simon.net.nz>:

It sounds like you have a design problem - For something like this, I'd go for a model like this:

I never said it is not possible to create models for everything you want to save. I just said if you have lots of such things it becomes an unnecessary hurdle to go thru. request.user.sessioncolor? = "red" *is* more convenient than creating/updating models. Messages was just an example. I can surely create models, the point is convenience. One text field in one table is definetly cheaper than dozens of tables/columns.

comment:6 Changed 8 years ago by SmileyChris

  • Resolution invalid deleted
  • Status changed from closed to reopened

It's still a design decision, but it is a valid ticket.

comment:7 Changed 8 years ago by anonymous

You're free to do this yourself but I'm not sure it belongs in the Django core. You can already use the pickle module to store things like this.

And for what its worth, 20 bool columns are almost certainly more efficient than storing pickled data, especially if you pick the right data types. Modern databases are very tolerant of high column counts.

comment:8 Changed 8 years ago by adrian

  • Resolution set to wontfix
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.
Back to Top