Currently, Entity._patch_write_model() recurses through nested models, as it strips away read-only fields from corresponding "read" models.
This includes Node.AttributesModel (assigned to Node.ReadModel.attributes). However, the cases of read-only attributes is small, limited to file-based data types (filename of a singlefile data, and in addition md5 for cif data). These are read-only, as they are derived from the corresponding file.
That said, we currently leave the door open for such fields. We could close it, reducing a good deal of code and maintenance burden, by strictly making attributes models entirely write-based (no read-only fields!). To resolve the above, derived fields must be defined as optional to allow the user to avoid having to provide them (filename is one thing, but we shouldn't expect users to compute a md5 hash). The consequence of this is mild schematic lying (the derived field is codified as optional, where in reality, it is derived and WILL be present). But I somehow feel like this is somewhat tolerable/acceptable. Optional means it might be present. The fact that in reality it always is perhaps does not really equate to lying.
Ideas welcomed!
@giovannipizzi
Currently,
Entity._patch_write_model()recurses through nested models, as it strips away read-only fields from corresponding "read" models.This includes
Node.AttributesModel(assigned toNode.ReadModel.attributes). However, the cases of read-only attributes is small, limited to file-based data types (filenameof a singlefile data, and in additionmd5for cif data). These are read-only, as they are derived from the corresponding file.That said, we currently leave the door open for such fields. We could close it, reducing a good deal of code and maintenance burden, by strictly making attributes models entirely write-based (no read-only fields!). To resolve the above, derived fields must be defined as optional to allow the user to avoid having to provide them (filename is one thing, but we shouldn't expect users to compute a md5 hash). The consequence of this is mild schematic lying (the derived field is codified as optional, where in reality, it is derived and WILL be present). But I somehow feel like this is somewhat tolerable/acceptable. Optional means it might be present. The fact that in reality it always is perhaps does not really equate to lying.
Ideas welcomed!
@giovannipizzi