On Fri, Aug 17, 2012 at 1:42 PM, Thomas Orozco <g.orozco.tho...@gmail.com> wrote: > Session key is the session 's primary key. Not the session itself. > > What you want to assign to your field is a session, not its key. So use > request.session. > > However. > > Please very careful when using FK' s to sessions, sessions are meant to be > short lived, and could / should be deleted once they expire (ie. When the > user logs off or after a specific duration), depending on your backend. > > I'm not sure what you're trying to achieve, but I think that FKing to > sessions is, at the very list, pretty risky. > > Especially given that the default on delete behavior of a ForeignKey is > cascade.
You are right. Actually, I want a cart like system. Like in my project's case, if a client want to test multiple material in one job, it should generate one bill and receipt. But for each different material, different jobs are created. So, I thought it could be achieved by storing the session in which the user logged and then get the bill generated based on that session. If you find it a vague solution, do tell the most optimum solution. -- Sandeep Kaur E-Mail: mkaurkha...@gmail.com Blog: sandymadaan.wordpress.com -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
