Hello,
Django can’t do this out of the box, but see this post[1] for a possible solution with dicts.
You might also want to look at serialization[2]; it might help you a bit, but again, it’s primarily for dicts, not lists.
On the other hand, I started wondering why you need this, do you care to share the use case?
Cheers,
Gergely
[1] http://stackoverflow.com/a/29088221/1305139
[2] https://docs.djangoproject.com/en/1.9/topics/serialization/
--
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...@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/CACwCsY7EZtbmLqLgggZnnBspKbvOucPDki1i28zD3jtjGp%3DWFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
`qs.filter(...info that is coming in...).exists()`
If ^ is True, then update it, otherwise create a new object?
They're not identical - there's a timestamp - that is not one of the
columns compared.
The data is status data from a piece of equipment and we only want to
store changes. If 2 consecutive rows come in that are the same
(excluding the timestamp) I don't want to store the second one.
On May 24, 2016 9:11 AM, "Derek" <game...@gmail.com> wrote:
>
> Interesting. In all the cases I can think of, I would almost always want to keep the most recent check (not the oldest)... that tells me how recently the status of X was checked. A more pedantic administrator might also want all those times stored, so a history can be created.
>
Not necessarily. You would want record of the initial change, not a record of the last time that value was seen. The assumption would be that the value remained constant until the next change event. What happens when the sensor goes offline and online, and then continues to report the same value on initialization? You wouldn't see anything until the sensor reported a changed value, which could be seconds, or years. That also means you've lost a data point that probably should have been captured.
In doing so, you also potentially save a ton of write operations, since keeping the latest check would require extra logic to delete the old entry and create the new entry, or update the existing entry in place.
The use case for the data would be the driver for what data needs to be retained. And also the use cases that haven't been thought of.
I personally would prefer to keep all of the data points, and summarize the data in a report using logic similar to the OP's storage strategy. People tend to find interesting ways to use data, and you always end up with egg on your face if you are summarizing/tossing the data on input rather than filtering/analyzing output.
Obviously this is all barring other technical restrictions that may enforce a reduced data set.
-James