Re: get all columns as a list

Just FYI, they did not want that change. They did not feel it added
any value. But in reality, they probably just didn't want me spending
time on it so I could do other things.

On Wed, May 25, 2016 at 9:35 AM, Larry Martell <larry.martell@gmail.com> wrote:
> I am the OP. I was implementing what my customer asked for. But you
> make a good point that they might want the latest data not the oldest.
> I will suggest that to them. Thanks.
>
> On Wed, May 25, 2016 at 9:29 AM, Derek <gamesbook@gmail.com> wrote:
>> We are both speaking as non-users of the OP's system. ;)
>>
>> I agree that there are some use cases for keeping the first measurement IF
>> the actual date of measurement makes no difference at all. We have an app
>> like that, where we process real-time data and use a filter that only lets a
>> record through if there has been a "change since previous". On the other
>> hand, changing the date means that the user has some reassurance that status
>> changes have been, and are, continuing to be made. I think we saying the
>> same thing though: in general, in the absence of other constraints, try to
>> retain as much data as possible and archive it in preference to simply
>> tossing it.
>>
>> On Wednesday, 25 May 2016 00:52:01 UTC+2, James Schneider wrote:
>>>
>>>
>>> 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

--
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+unsubscribe@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/CACwCsY628aLDZuw1iDfNCERBWtMJM5CdbqqA%3De%2BdNDO7hNwjUw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.