You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Discovered in a particular dataset whose map_item returned a {} on the first item. This causes a number of issues in itself, but seemed to first strike get_item_keys which would return an empty list and cause various failures. Some very odd behavoir was noted with the processor options on this bad dataset: they returned different column options than expected. It seems probable that something fails when calling get_columns (which in this case returns a []) and instead of raising an error, the options for another dataset or perhaps call of get_options is used instead. Likely something is not being updated properly due to the [].
Interestingly, I was able to modify get_item_keys to correctly return a list of keys (by iterating map_item until a {} was not returned) and updated the view_datasets preview function to use this method. When doing that, the processor options were properly loaded from that dataset. It is my opinion that they should not since get_columns was not updated and it directly collects keys from the first item in the dataset!
The text was updated successfully, but these errors were encountered:
When we call get_options, we usually set options = cls.options and then check if parent_dataset and parent_dataset.get_columns(): before updating options. That is going to be False if get_columns returns an empty []. And then get_options just returns the cls.options which is whatever it was set to last.
options = {} is actually in BasicProcessor, so it's possible that all of our subclasses can access the same options. We just happen to be setting them and updating them before we use them. Not ideal and possible difficult to fix without breaking anything else. Unsure.
Removing options = {} from BasicProcessor not enough. Somehow options are still sharing. Interestingly, I ran a rank values processor and the column options afterwards were "date", "item", and "value". As if that dataset was being used (is get_options being called on that dataset somewhere? Perhaps to find available sub processors...).
Describe the bug
Discovered in a particular dataset whose
map_item
returned a{}
on the first item. This causes a number of issues in itself, but seemed to first strikeget_item_keys
which would return an empty list and cause various failures. Some very odd behavoir was noted with the processor options on this bad dataset: they returned different column options than expected. It seems probable that something fails when callingget_columns
(which in this case returns a[]
) and instead of raising an error, the options for another dataset or perhaps call ofget_options
is used instead. Likely something is not being updated properly due to the[]
.Interestingly, I was able to modify
get_item_keys
to correctly return a list of keys (by iteratingmap_item
until a{}
was not returned) and updated the view_datasets preview function to use this method. When doing that, the processor options were properly loaded from that dataset. It is my opinion that they should not sinceget_columns
was not updated and it directly collects keys from the first item in the dataset!The text was updated successfully, but these errors were encountered: