Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change persistence handling to standardize saving dictionaries as json in JsonUtil.encode_object #557

Closed
ernstleierzopf opened this issue Mar 16, 2021 · 7 comments
Assignees
Labels
refactor Issues with coding style

Comments

@ernstleierzopf
Copy link
Contributor

For example like in the EFD:

for log_ev, freq in self.counts_prev.items():
persist_data.append((log_ev, freq))

@ernstleierzopf ernstleierzopf self-assigned this Mar 16, 2021
@ernstleierzopf ernstleierzopf added the refactor Issues with coding style label Mar 16, 2021
@ernstleierzopf ernstleierzopf added this to the Release 2.3.0 milestone Mar 16, 2021
@4cti0nfi9ure 4cti0nfi9ure removed this from the Release 2.3.0 milestone Jun 25, 2021
@ernstleierzopf
Copy link
Contributor Author

Idea: use the old pull request to create a concept of persisting data and adapt it at a per class basis.

@ernstleierzopf
Copy link
Contributor Author

Also change persistence after creating new unittests - wait before a major release.

@ernstleierzopf
Copy link
Contributor Author

ToDo after unittests for the analysis classes are created - always also check the persisted data format on disk. These are breaking changes and need to be done before a new release.

@ernstleierzopf
Copy link
Contributor Author

save ETD data as dictionary.

@ernstleierzopf
Copy link
Contributor Author

#300 is related.

@ernstleierzopf
Copy link
Contributor Author

I think there will never be a good opportunity to implement this this issue, because these would be breaking changes for existing deployments. There could be an automatic tool to update existing persisted data, but it might not be worth the implementation time and risks involved. The benefits simply do not outweight the risks and hassle.

@landauermax do you agree?

@landauermax
Copy link
Contributor

Yes I agree, it is high risk and not worth it just for the sake of standardization.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactor Issues with coding style
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants