Keeping a list of UIDs in-sync in this case is challenging, cause we need to keep that list up-to-date in event subscribers (on creation and on removal). And this might entail issues (e.g. you never know which subscriber is called first). Reason is that, except on sample creation and on manage analyses, we always create analyses programmatically (e.g by using create_analysis. For instance, when we create a retest.
Making getRaw to rely on instance.objectValues('Analysis') instead of relying on an object attribute could be considered as an alternative. However, objectValues wakes up all the contained objects. A query against the catalog will be faster, cause we get brains instead. In such scenario, there is no benefit compared to what we had before https://github.com/senaite/senaite.core/pull/2593 . Likewise, having an inconsistency between the values returned by getRaw and get is also not worth.
Therefore, this Pull Request reverts back the attribute Analyses that was handled by ARAnalysesField and although it keeps the getRaw function, it is now consistent with the brains returned by default by get.
Current behavior before PR
Too many side-effects because of the need of keeping Analyses attribute up-to-date
Desired behavior after PR is merged
Analyses UIDs are no longer kept in an object attribute. getRaw is consistent with getAnalyses
--
I confirm I have tested this PR thoroughly and coded it according to PEP8
and Plone's Python styleguide standards.
Description of the issue/feature this PR addresses
getRawfunction forARAnalysesFieldwas introduced with https://github.com/senaite/senaite.core/pull/2593 , but there are too many side-effects.Keeping a list of UIDs in-sync in this case is challenging, cause we need to keep that list up-to-date in event subscribers (on creation and on removal). And this might entail issues (e.g. you never know which subscriber is called first). Reason is that, except on sample creation and on manage analyses, we always create analyses programmatically (e.g by using create_analysis. For instance, when we create a retest.
Making
getRawto rely oninstance.objectValues('Analysis')instead of relying on an object attribute could be considered as an alternative. However,objectValueswakes up all the contained objects. A query against the catalog will be faster, cause we get brains instead. In such scenario, there is no benefit compared to what we had before https://github.com/senaite/senaite.core/pull/2593 . Likewise, having an inconsistency between the values returned bygetRawandgetis also not worth.Therefore, this Pull Request reverts back the attribute
Analysesthat was handled byARAnalysesFieldand although it keeps thegetRawfunction, it is now consistent with the brains returned by default byget.Current behavior before PR
Too many side-effects because of the need of keeping
Analysesattribute up-to-dateDesired behavior after PR is merged
Analyses UIDs are no longer kept in an object attribute.
getRawis consistent withgetAnalyses-- I confirm I have tested this PR thoroughly and coded it according to PEP8 and Plone's Python styleguide standards.