-
Notifications
You must be signed in to change notification settings - Fork 4
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
Mitigate next_etrago_id
collisions
#927
base: dev
Are you sure you want to change the base?
Commits on Sep 7, 2022
-
Update the pre-commit configuration
Done simply via `pre-commit autoupdate`. Should fix all pre-commit issues.
Configuration menu - View commit details
-
Copy full SHA for 049b185 - Browse repository at this point
Copy the full SHA 049b185View commit details -
Tell flake8 that this bare
except
is OKOtherwise it would complain with "E722 do not use bare 'except'".
Configuration menu - View commit details
-
Copy full SHA for 3ad23ba - Browse repository at this point
Copy the full SHA 3ad23baView commit details -
Use (parts of) a UUID4 as the
next_etrago_id
I did a few experiments and using six bytes of the UUID would've been OK but risky, but using seven bytes didn't lead to collisions for up to around 1.6e+10 UUIDs in around 3e+5 contiguous ranges with random lengths from 1e+4 to 1e+5. Using eight bytes would mean the risk of generating integers which are to big for PostgreSQL's BigInt datatype, so seven bytes is the best compromise between simplicity and collision mitigation.
Configuration menu - View commit details
-
Copy full SHA for da7703b - Browse repository at this point
Copy the full SHA da7703bView commit details -
This is due to a "flake8" complaint, but it also makes the code more explicit. The intention is to provide an alternative, should the `dataset_2040[node]` lookup fail. Explicitly catching only the `KeyError` caused by this avoids potentially hiding other errors. There's still a bug in this code, as explained in issue #926, but that's something which has to be fixed separately.
Configuration menu - View commit details
-
Copy full SHA for 0cb29fc - Browse repository at this point
Copy the full SHA 0cb29fcView commit details -
Fix style and clean up the code
Most of these are done automatically via "isort" or "black". The exceptions are: - fixing the line length of SQL strings and comments, - removing trailing whitespace in SQL strings and - removing the unused local variable `sources`. These things had to be done manually to ensure they really don't change the semantics of the code.
Configuration menu - View commit details
-
Copy full SHA for 7876b1f - Browse repository at this point
Copy the full SHA 7876b1fView commit details -
Reformat "emobility/**/model_timeseries.py"
There's some interesting stuff in here. First, some of the lines, the ones within the `# fmt: on`/`# fmt: off` blocks, could not be formatted by "black" due to psf/black#510. Second, I had to wrestle with "isort" quite a bit because it kept formatting the imports to be too long so I had to resort to the `# noqa: E501` solution. Last but not least, if an import is only used in a docstring, "flake8" doesn't seem to recognize it as used.
Configuration menu - View commit details
-
Copy full SHA for 81bca5f - Browse repository at this point
Copy the full SHA 81bca5fView commit details -
Stop incrementing
next_etrago_id
resultsSince the IDs are randomly generated now, there's no reason to increment them anymore. Both variants are (roughly) equally likely to collide with IDs already in use.
Configuration menu - View commit details
-
Copy full SHA for 91af5d2 - Browse repository at this point
Copy the full SHA 91af5d2View commit details -
Fix various style issues in "datasets/gas_grid.py"
Mostly overly long lines but also one missing space after an inline comment (`#`) sign and one f-string without placeholders.
Configuration menu - View commit details
-
Copy full SHA for cdc3220 - Browse repository at this point
Copy the full SHA cdc3220View commit details -
Remove superfluous casts to
int
The result of `next_etrago_id` is now always an `int` so no need to cast it.
Configuration menu - View commit details
-
Copy full SHA for ed6e456 - Browse repository at this point
Copy the full SHA ed6e456View commit details -
Configuration menu - View commit details
-
Copy full SHA for 4ad629d - Browse repository at this point
Copy the full SHA 4ad629dView commit details -
Move
next_etrago_id
calls closer to use sitesAt least where possible. I also took the liberty of removing comments like `# Select next id value` because these just restate the name of the function in other words so one could argue that they should fall into a category of comments which should be avoided according to [PEP8][0]. [0]: https://peps.python.org/pep-0008/#inline-comments
Configuration menu - View commit details
-
Copy full SHA for 7c1a2ac - Browse repository at this point
Copy the full SHA 7c1a2acView commit details -
Configuration menu - View commit details
-
Copy full SHA for 99c2b15 - Browse repository at this point
Copy the full SHA 99c2b15View commit details -
Since we now generate IDs randomly, they are no longer "guaranteed" to be the current maximum so the old name is misleading.
Configuration menu - View commit details
-
Copy full SHA for a223112 - Browse repository at this point
Copy the full SHA a223112View commit details -
The respective code blocks kind of belong together and having them closer to each other makes this a little bit more obvious. See also the [PEP8 note][0] on using "blank lines [..] sparingly". [0]: https://peps.python.org/pep-0008/#blank-lines
Configuration menu - View commit details
-
Copy full SHA for 085448a - Browse repository at this point
Copy the full SHA 085448aView commit details -
Fix potentially dangerous duplicate calls
Calling `next_etrago_id` two times in "close" succession did not guarantee getting the same results even before switching to random IDs. This was due to concurrency. Now that we're using random IDs, these two calls are basically guaranteed to yield wildly different results (which is the point of the new implementation), so this pattern is very dangerous and will nearly always be wrong. Fortunately it is easily fixed by saving the result of the first call and using it in place of both calls.
Configuration menu - View commit details
-
Copy full SHA for 5593c82 - Browse repository at this point
Copy the full SHA 5593c82View commit details -
Turns out that it's not possible to import `MotorizedIndividualTravel` because it leads to a circular import. Solution: ``` import egon.data.datasets.emobility.motorized_individual_travel ``` instead and pull `MotorizedIndividualTravel` out of it at use time.
Configuration menu - View commit details
-
Copy full SHA for c194284 - Browse repository at this point
Copy the full SHA c194284View commit details