Optionally yield incomplete datasets #1
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
(Reported by @reiche)
Currently,
repack"hides" incomplete datasets:This is for many use cases the correct behavior since incompleteness is temporary (i.e., it happens for one out of many) ...
If the incompleteness is continued because a devices is not sending anything, we get stuck waiting for complete data.
Ideas:
I would prefer that per default and incomplete dataset is returns with Nones. Otherwise a lot of my programs would crash since I access the data record by the list of requested channels. It has a higher change to handle 'Nones' than missing keys.
But it should be able to have a flag to allow for valid datasets, where None entries are excluded.
Independent I would add a warning in the routine run() of BSCache for incomplete dataset similar to the case that the msg is None.
It should be the exact same change, TBH.
The idiomatic pattern is to replace
with
and then something like
or
But, this also allows for:
for cases where you know the default you want to use...
Anyway, I think I will have to keep the default behavior as it is now, and make the other options configurable via an argument to the BSCache constructor...
It would work for me but I have to check all programs where I read from the bs-stream via BSCache.
I typically go through all my codes once every year to make a sanity check.
It would be one grep for "BSCache" and then changing the relevant ones to:
or something similar.
And
handle_incompletecould be:Or something similar...
Hi Sven,
I would at least implement for handle_incomplete = None are message (at least once) that the dataset is incomplete without raising a ValueError. At least that way one can see where the program is hanging.
For me it was not so much the problem that it behaves at it is but not know that it is in this state.
It helps also the operator to inform the general problem that the bstream returns incomplete data, which is a nore general problem the operator should be aware of.
In the mean time I will go through my code and catch the possibility to handle these different cases.
Oh sure, the warning+counter should be there for all cases...