user sessions

[upadhyay@…]

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.

[Ben Slavin <benjamin.slavin@…>]

-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.

[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.

[Simon G. <dev@…>]

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

[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.

[Chris Beaven]

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

[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.