Expiration date option

[David Turner]

Being new to Django I have a problem which I am not able to resolve.

I have a model which has the following fields:
expiry_date = models.DateField(null=True, blank=True,)
has_expired = models.BooleanField(verbose_name='Has Expired',
                                                           default=True, )

I need to keep expired items in the database for reporting purposes.

My question is how do I  show only the non-expired items in my views.?

Would the solution be via a model manager?

Any help would be appreciated

[James Schneider]

Probably, yes.

If you only need to filter out expired items in a single view, you may just want to override/append the query set used in that single view with filter(has_expired=False).

If you plan on needing this query filtering in multiple locations, then you'll want to create a custom model manager method that includes the desired filter.

On a side note, you may not need the has_expired fields at all if your business logic dictates that any instance with an expiry_date that has already passed should be considered expired. It would mitigate the need for the extra logic to keep the has_expired field in sync with the expiry_date. Otherwise you may end up with objects with an expiry_date in the future but showing expired, and vice versa. I try to avoid those types of field dependencies, and DB normalization purists will likely complain about it.

-James

[David Turner]

Hi

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?

Thanks

-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...@googlegroups.com.
To post to this group, send email to django...@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%2BciVY43_D-9YF9PK_intnsEkd%2BRDJoSVr6h-O79%2BzP%2B3Gcg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[James Schneider]

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

[David Turner]

Many thanks for the answer especially the amount of detail in it.

Best

-david

-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...@googlegroups.com.
To post to this group, send email to django...@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.

[David Turner]

Hi James

Just one more quick question:
I have two django models both containing the same information, temps and companies.
The models both contain the following fields:

odd days
weekends
nights
emergencies

Currently this allows me to filter on these fields in django admin.
My question is would I be better treating these as a many to many model and using them that way and how would I filter them in django admin?

Best

-david

[James Schneider]

On Wed, Jun 8, 2016 at 9:25 AM, 'David Turner' via Django users <django...@googlegroups.com> wrote:

Hi James

Just one more quick question:
I have two django models both containing the same information, temps and companies.
The models both contain the following fields:

odd days
weekends
nights
emergencies

Currently this allows me to filter on these fields in django admin.
My question is would I be better treating these as a many to many model and using them that way and how would I filter them in django admin?

I have not used the admin much beyond the tutorial, so any answers from me would be less than useful.

I don't quite understand the question. The only reason you would connect them with a M2M would be if the two models had some sort of relationship with each other. I don't think I have enough information to provide a recommendation one way or the other. Ease of filtering in the admin should have less influence than the business use case for model design.

I'm also not entirely sure what 'temps' refers to (temporary employees?), which doesn't help my understanding of the question.

If you have two models that contain the same information, would it be more prudent to combine them into a single more generic model and separate/filter them by some sort of categorical field? For example, you might have a model for a Car, and a model for a Truck, but both could potentially be lumped together in a more generic model called Automobile, or Vehicle (which is even more generic). Automobile could have a 'vehicle_class' attribute that would designate it as a 'car', 'truck', etc. It's really dependent on the business use case and whether or not there is enough difference between the two classes of vehicles to warrant having separate models. Think of separate models from a very high level like "I need all the car-like things over here, and all the people-like things over here." Your models usually won't get more specific than that unless there is a specific reason to do so. 

Even if the business logic was different, but the underlying data structure was the same, you could employ proxy models for 'Automobile' named 'Car' and 'Truck' that have overlapping model methods with different behavior (but are maintained within the same DB table). 

I feel like I'm rambling on a tangent, so I'll stop there. 

-James

[David Turner]

Hi James

Thanks for your answer as it has made me go back to putting business logic first which has then enabled me to come up with the right solution.

Best

-david

--

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...@googlegroups.com.
To post to this group, send email to django...@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%2BciUfDrBMkidPi-GF9Lw%3DOn-maoBgsAxKUpvfcma5QZG2fg%40mail.gmail.com.