BaseDataObject provides is_dirty, a property that's intended to indicate when the state data of an object has been changed (for example, it should be set to True when any of the various _set_ or _del_ methods have been called). Since the concrete objects' property setter and deleter methods, as defined in their corresponding base classes, aren't aware of that capability at all, it's up to the concrete objects to implement that functionality.

However, since those setter and deleter methods can be called in the derived concrete class definitions, the implementation is very straightforward. Using the address property of Artisan as an example, we essentially define local setter and deleter methods that call their counterparts in BaseArtisan:

###################################
# Property-setter methods         #
###################################

def _set_address(self, value:Address) -> None:
    # - Call the parent method
    result = BaseArtisan._set_address(self, value)
    self._set_is_dirty(True)
    return result

# ...

###################################
# Property-deleter methods        #
###################################

def _del_address(self) -> None:
    # - Call the parent method
    result = BaseArtisan._del_address(self)
    self._set_is_dirty(True)
    return result

Once those are defined, the property itself has to be redefined in order to point to the appropriate methods. Without this step, the Artisan objects' properties would still point to the BaseArtisan setter and deleter methods, so the is_dirty flag would never get set, and data changes would never be saved:

###################################
# Instance property definitions   #
###################################

address = property(
    BaseArtisan._get_address, _set_address, _del_address, 
    'Gets, sets or deletes the physical address (Address) '
    'associated with the Artisan that the instance represents'
)

This same pattern will play out for all of the properties of the hms_artisan classes.

That also means, however, that all of those classes, since they all use their various _del_ methods to initialize instance values during the execution of their __init__ methods, may also need to explicitly reset is_dirty to False when an object is created.

This is a very simplistic approach to handling the dirty state of object instances. The fundamental assumption behind this implementation is that any property setting or deletion that occurs will make a change to the applicable state value, so the instance is dirty as a result. Even if the new value was the same as the old value of a property, this would be the case. In systems where there is an actual monetary cost for each database transaction (some cloud-based data stores), it might be worth the additional effort of checking the property value before executing the set code or delete code, and not even making the change, let alone setting the is_dirty flag, if the incoming new value isn't different from the existing one.