Use simple unchangable identifiers for partition names #19
Milestone
Comments
Closed
jcjones
added a commit
that referenced
this issue
Sep 20, 2021
In the real world, we might mess up when naming a partition. This should be rare if partitionmanager is running often, since it'll rename partitions to match reality, but when it's running only rarely, things get out of date. This change avoids attempting to calculate rates-of-change using partitions that don't make sense - e.g., today is July 1, and our active partition says it starts in a week. That is plainly wrong, but we can still use our current rate-of-change. This expands on PR #12 by changing what the start-datetime is for new partitions after we mispredicted - without this change, if we had partitions through to December, but it's only August and we need more, the new partitions would be named for January instead of reflecting reality that they need to be named for Right Now. This also catches a bug where we could get timestamp name collisions. This is a lot less of an issue when I implement Tim's suggestion in #19, but for now this just increases dates by a day to avoid a collision, and that works well.
jcjones
added a commit
that referenced
this issue
Sep 21, 2021
In the real world, we might mess up when naming a partition. This should be rare if partitionmanager is running often, since it'll rename partitions to match reality, but when it's running only rarely, things get out of date. This change avoids attempting to calculate rates-of-change using partitions that don't make sense - e.g., today is July 1, and our active partition says it starts in a week. That is plainly wrong, but we can still use our current rate-of-change. This expands on PR #12 by changing what the start-datetime is for new partitions after we mispredicted - without this change, if we had partitions through to December, but it's only August and we need more, the new partitions would be named for January instead of reflecting reality that they need to be named for Right Now. This also catches a bug where we could get timestamp name collisions. This is a lot less of an issue when I implement Tim's suggestion in #19, but for now this just increases dates by a day to avoid a collision, and that works well.
|
I kinda wonder if we should instead use a non-date numbering scheme, just something starting from 0, so we can strip all the logic for maintaining names out. |
|
This still causes spurious DuplicatePartitionExceptions. |
|
See #46 |
|
After #51, we should stop performing renames of partition names to "keep them correct" and instead either keep them as their initial prediction, or (better yet) use an incrementing simple identifier that does not change. |
jcjones
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After #51, we should stop performing renames of partition names to "keep them correct" and keep them as a simple identifier that does not change.
The text was updated successfully, but these errors were encountered: