Ilya Semenov wrote: > What different approach could I choose? I'm writing real-life model - > a Ticket can either have a User (who resolved it), or not (if the > ticket has not been yet resolved). Listing all resolved Tickets with > corresponding Users is a simple real-life task, too.
Indeed... However Django does not implement it as of now. It would be fine if you create (or just find) a ticket on this issue in Django Trac (http://code.djangoproject.com/). Note, though, that the code dealing with query construction is undergoing a heavy refactoring so it may take a while to implement this behavior. > How do I find a different approach? The only solution which comes to > my mind is to create a "special" User with id=0, and make all None > references point to it instead, but this seems very unnatural and > hackish to me. I'd suggest to do just this (not exactly with some special id but with some special username). This is, in fact, one of the classic refactorings from M. Fauler's book -- "Introduce NULL object". In short, having an object that acts as "nobody", "nothing", "not initialised" etc is more convenient than having the field just NULL because then there are far less places where you should do NULL checks. For example (simplified) you can set username to "nobody" and in a template write: {{ ticket.user }} instead of: {% if ticket.user %}{{ ticket.user }}{% else %}nobody{% endif %} --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
