Opened 17 years ago

Closed 17 years ago

#3776 closed (wontfix)

user sessions

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

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 by Ben Slavin <benjamin.slavin@…>, 17 years ago

-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 by Gary Wilson <gary.wilson@…>, 17 years ago

Triage Stage: UnreviewedDesign decision needed

in reply to:  1 comment:3 by anonymous, 17 years ago

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 by Simon G. <dev@…>, 17 years ago

Resolution: invalid
Status: newclosed

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()

in reply to:  4 comment:5 by anonymous, 17 years ago

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 by Chris Beaven, 17 years ago

Resolution: invalid
Status: closedreopened

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

comment:7 by anonymous, 17 years ago

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 by Adrian Holovaty, 17 years ago

Resolution: wontfix
Status: reopenedclosed
Note: See TracTickets for help on using tickets.
Back to Top