One of the things that went away with the new operation subsystem is how some operations marked their results as “clean” vs “dirty”. This is what the modelbuilder app and the descriptive phrase system used to decide whether models needed to be saved or not. I have a feeling we will want to change how it is done but don’t know if it is important for the SMTK/CMB release.
Previously, operations such as “read” and “write” added a VoidItem named “cleanse entities” that indicated associated models (not resources) should be marked clean (as is true immediately after a read or write, but not after import/export or most other operations). Lacking that, the base operator class would mark the owning model as dirty. See doc/userguide/model/operators.rst line 103 for details. The docs should be updated based on what we decide; at a minimum, I expect we really want to mark resources not models as clean.
I’ve updated the descriptive phrase stuff to show clean/dirty markings and it will appear in a MR soon.
TJ has already added methods to mark resources this way, but the current use of these methods appears haphazard (polygon and the base model SessionIOJSON classes call it; nothing else does — including the attribute read/write operations). This is one of the reasons I prefer a default behavior for operations to mark their operands’ resources dirty.
Should I file an issue against SMTK 3.0? CMB 6.0? Something else?
Do you have feelings about something to automatically mark resources dirty/clean? At least some helper methods? Or a way to test operations to ensure they mark properly?
Previously, operations such as “read” and “write” added a VoidItem named “cleanse entities” that indicated associated models (not resources) should be marked clean (as is true immediately after a read or write, but not after import/export or most other operations).
I really didn’t like the idea of “encoding” actions into operators’ attributes without those pieces being present in a base operator result description.
Lacking that, the base operator class would mark the owning model as dirty.
I think this was better than the above method, but it still made use of run-time “properties” to describe information that is known at compile time (the Write operation knows at compile time that, upon success, its resource should be marked as clean).
TJ has already added methods to mark resources this way, but the current use of these methods appears haphazard (polygon and the base model SessionIOJSON classes call it; nothing else does — including the attribute read/write operations).
Not sure if it was me who added these methods (I fixed the comment style of the methods to match the rest of the class), but I agree that their use has been haphazard. In fact, the implementation of all operation results involving resources (as opposed to components) has been haphazard to date (and I am largely to blame); their inclusion into operation results warrants a discussion.
Do you have feelings about something to automatically mark resources dirty/clean? At least some helper methods? Or a way to test operations to ensure they mark properly?
Couldn’t we inspect the “created”, “modified” and “expunged” components and simply mark their resources as dirty? As for marking resources as clean, once we agree on a uniform way of marking resources (preferably using compiled API), it would likely be a single function call in a small subset of operations (the ones that write). Unless I am missing something, do we need additional code/helper methods to accomplish this?
I think this was better than the above method, but it still made use of run-time “properties” to describe information that is known at compile time (the Write operation knows at compile time that, upon success, its resource should be marked as clean).
I’m not sure that every use case is known at compile time… for instance, an undo operation.
The fact that a resource may be clean or dirty is what is known at compile time. Run-time information is better suited to definitions that are unknown at compile time (e.g. a VTK model marked as for use by simulation A or simulation B).
Couldn’t we inspect the “created”, “modified” and “expunged” components and simply mark their resources as dirty?
Are expunged components guaranteed able to provide a pointer to their resource? Model entities can, but others?
That’s a good point. Expunged components are a tricky and outstanding piece to consider.