-
Notifications
You must be signed in to change notification settings - Fork 10
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
[Feature] Add a SQL Database #14
Comments
dlatypov
added a commit
to dlatypov/lkml-gerrit-bridge
that referenced
this issue
Nov 18, 2020
Problem: Non-deterministic change ids mean we get duplicate changes uploaded to Gerrit for the same patch if the Bridge gets restarted. When issue google#14 is implemented, this will not matter as much, but there's still a chance for updates not to be persisted in the DB. Solution: Use a deterministic change id, i.e. "I" + <commit sha of v1>. If we try and create a Gerrit change for the same patch, I'm assuming the collision with the pre-existing change id will prevent us from doing so. Alternative: As noted in the file, we could consider using a `applypatch-msg` hook. But we can do more if we edit the commit directly from Python, since we have access to more information, e.g. the lore link. Add in a "Lore-Link" footer while we're here to demonstrate this. This iteration of the code is essentially a direct translation of what I had originally prototyped in bash for the hook.
dlatypov
added a commit
to dlatypov/lkml-gerrit-bridge
that referenced
this issue
Nov 18, 2020
Problem: Non-deterministic change ids mean we get duplicate changes uploaded to Gerrit for the same patch if the Bridge gets restarted. When issue google#14 is implemented, this will not matter as much, but there's still a chance for updates not to be persisted in the DB. Solution: Use a deterministic change id, i.e. "I" + <commit sha of v1>. If we try and create a Gerrit change for the same patch, I'm assuming the collision with the pre-existing change id will prevent us from doing so. Alternative: As noted in the file, we could consider using a `applypatch-msg` hook. But we can do more if we edit the commit directly from Python, since we have access to more information, e.g. the lore link. Add in a "Lore-Link" footer while we're here to demonstrate this. This iteration of the code is essentially a direct translation of what I had originally prototyped in bash for the hook.
dlatypov
added a commit
to dlatypov/lkml-gerrit-bridge
that referenced
this issue
Nov 18, 2020
Problem: Non-deterministic change ids mean we get duplicate changes uploaded to Gerrit for the same patch if the Bridge gets restarted. When issue google#14 is implemented, this will not matter as much, but there's still a chance for updates not to be persisted in the DB. Solution: Use a deterministic change id, i.e. "I" + <commit sha of v1>. If we try and create a Gerrit change for the same patch, I'm assuming the collision with the pre-existing change id will prevent us from doing so. Alternative: As noted in the file, we could consider using a `applypatch-msg` hook. But we can do more if we edit the commit directly from Python, since we have access to more information, e.g. the lore link. Add in a "Lore-Link" footer while we're here to demonstrate this. This iteration of the code is essentially a direct translation of what I had originally prototyped in bash for the hook.
bjh83
pushed a commit
that referenced
this issue
Nov 18, 2020
Problem: Non-deterministic change ids mean we get duplicate changes uploaded to Gerrit for the same patch if the Bridge gets restarted. When issue #14 is implemented, this will not matter as much, but there's still a chance for updates not to be persisted in the DB. Solution: Use a deterministic change id, i.e. "I" + <commit sha of v1>. If we try and create a Gerrit change for the same patch, I'm assuming the collision with the pre-existing change id will prevent us from doing so. Alternative: As noted in the file, we could consider using a `applypatch-msg` hook. But we can do more if we edit the commit directly from Python, since we have access to more information, e.g. the lore link. Add in a "Lore-Link" footer while we're here to demonstrate this. This iteration of the code is essentially a direct translation of what I had originally prototyped in bash for the hook.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, message_dao.py is just a wrapper for a dictionary. This should be changed to use a SQL Database like PostgreSQL.
The text was updated successfully, but these errors were encountered: