Many thanks for the answer especially the amount of detail in it. Best
-david On 8 June 2016 at 09:26, James Schneider <jrschneide...@gmail.com> wrote: > > > > Many thanks for your answer which makes perfect sense and yes, this is > only required for a single view. > > The expiry_date is needed as items are listed by expiry date. So would > you suggest removing the has_expired and writing the filter against the > expiry date? > > > > Yes, I meant that you should keep the expiry_date field, but eliminate the > has_expired field. I had a minor typo above that made it sound like you > should eliminate both fields, which is not the case. > > BTW, I would also suggest changing expiry_date to expiry_datetime and > store a full date/time object in it (if you aren't already) to remove > ambiguity down the road. You don't want to have to remember that the expiry > happens at 00:00 or 07:42 or whether or not the date is inclusive or > exclusive on the last day, etc. Using a single point in time makes life > grand for you and anyone working on your code who isn't you. All datetimes > should be timezone aware and stored in UTC if possible. > > Regarding writing the filter against expiry_datetime instead of > has_expired, the answer is yes, I would suggest doing so. The query is > probably marginally more expensive, but code cleanliness and maintenance > overhead make it worth it in most cases. > > I would add an asterisk to my answer though: > > *only if an object should be considered in an "expired" state if the > current (or given) date/time is greater than the expiry_datetime. If the > expiry_datetime is in the future, consider the object "not expired". > > Actually my entire answer is predicated on the * statement above being > accurate as my assumption. > > You will likely end up writing a custom model manager method down the > road, especially if you commonly filter against other fields like > "is_disabled" where you would need only objects that are not expired and > are active/not disabled. > > -James > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-users/aSj3jGX2CLk/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/CA%2Be%2BciVdqmrjPsnc1U2rkerTRC-1HrSPWE%3D9Q%2Bx%3DDOE4P6BEzQ%40mail.gmail.com > <https://groups.google.com/d/msgid/django-users/CA%2Be%2BciVdqmrjPsnc1U2rkerTRC-1HrSPWE%3D9Q%2Bx%3DDOE4P6BEzQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CALwQ%2B-tCXfsJsTYwsgAesLcQWH2VxznSnxzH0c1_iR0jTGgUig%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
