On 10/06/2022 11:24 pm, Ryan Nowakowski wrote:
> On Fri, Jun 10, 2022 at 05:52:48PM +1000, Mike Dewhirst wrote:
>> The use case is auto-deletion of out-of-date records if they have not
>> changed.
>>
>> That might sound weird but it is the solution I have come to for a
>> particular problem. My software analyses chemical properties and writes note
>> records containing advice, each with a FK to the chemical.
>>
>> When values change sufficiently on the chemical, the software would
>> construct a set of mostly different note records. The problem is that note
>> records still exist from the previous set of properties. These would
>> definitely confuse the user and thereby invalidate the advice.
> You might consider versioning your chemical model objects. Then when
> values change sufficiently on the chemical model object, you can create
> a new version of the chemical object, leaving the old notes associated
> with the old version of the chemical object. In your web app, you could
> allow the users to browse old versions of the chemical including the
> notes which may have been altered.
That's not really appropriate. The user doesn't care about older
versions beyond annual an summary of the calculated analysis. As volumes
(manufactured and/or imported) change the analysis and therefore current
advice changes. There is no need to keep track of out-of-date advice notes.
What really matters is that *when* things change the advice needs to
change and the old advice needs to be deleted.
The only reason I need to avoid deleting old notes is if the user has
edited the advice itself - in any of the the individual notes. Probably
it would be OK to delete an edited note because it is old advice BUT I
feel it would be wrong for software to make that decision. As I said,
I'm happy to document why.
Just thinking about that, I could maybe adjust the note.title to append
something like "Out of date" if I detect it has been edited.
>
>> The workaround is for the user to delete all notes *prior* to re-saving and
>> auto-generating a new correct set of notes. There is a proviso that you
>> wouldn't want to delete notes altered by users. I would document that so
>> users understand why the software skipped deleting those notes.
>>
>> I think the solution might be to hash note.title and note.note into a new
>> field note.hash on being auto-created. On subsequent saves, compare the
>> latest hash with note.hash to decide whether to delete auto-inserted notes
>> prior to generating the next set. Those subsequent saves could be months or
>> years later.
> Hashing is useful if you want to check that something has been
> unexpectedly changed. I assume the note can only be changed through
> your web app so you know when a user is changing a note.
These are automatically generated notes which taken together constitute
advice on how to deal with the analysis. Users can edit them. For
example, someone might record some action taken regarding the advice. I
don't want to delete that. If nothing has been edited, it is safe to delete.
So how do I know it is the same as when originally generated - and safe
to delete - except by storing a hash of the interesting fields.
And if that is the best approach, what sort of hashing will survive
Python upgrades etc?
> Since you're
> expecting users to change some of the notes and you know when they do,
> hashing might be overkill. Instead, add a boolean `altered_by_user`
> field to the note model. Initially when you automatically create the
> note altered_by_user would be set to False. If a user changes the note,
> set altered_by_user to True.
Not sure this would work. Note creation and eventually automatic
deletion is all driven from model methods executed on saving.
>
>> If unchanged, the old note is safe to delete because it is no longer
>> relevant.
>>
>> I've googled around and there are lots of possible solutions but it seems
>> the major problem might be that hashes are difficult to guarantee when the
>> environment - such as the version of Python - changes.
>>
>> Also, I'm not convinced I have chosen the correct strategy.
>>
>> Hope I've explained the problem adequately.
>
>