Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upSync PG annotations to ES #3242
Conversation
chdorner
added
the
WIP
label
Apr 22, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
codecov-io
Apr 22, 2016
Current coverage is 74.60%
- 4 files (not in diff) in
hwere modified. more- Misses
+8 - Partials
+3 - Hits
+17
- Misses
- File
h/app.pywas modified. more- Misses
+9 - Partials
0 - Hits
0
- Misses
@@ master #3242 diff @@
==========================================
Files 125 125
Lines 4644 4693 +49
Methods 0 0
Messages 0 0
Branches 550 554 +4
==========================================
+ Hits 3475 3501 +26
- Misses 1089 1108 +19
- Partials 80 84 +4 Powered by Codecov. Last updated by a7e521f...3988171
codecov-io
commented
Apr 22, 2016
•
Current coverage is 74.60%
@@ master #3242 diff @@
==========================================
Files 125 125
Lines 4644 4693 +49
Methods 0 0
Messages 0 0
Branches 550 554 +4
==========================================
+ Hits 3475 3501 +26
- Misses 1089 1108 +19
- Partials 80 84 +4
|
chdorner
removed
the
WIP
label
Apr 25, 2016
nickstenning
reviewed
Apr 25, 2016
| @celery.task | ||
| def add_annotation(id_): | ||
| annotation = storage.fetch_annotation(celery.request, id_) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
nickstenning
Apr 25, 2016
Contributor
Ah, ok. This is a good idea, but you're going to need to be a bit careful if you do this. Because the view function is called inside a transaction, that means that you're going to be calling add_annotation.delay(id) while the transaction is still open.
While not likely in practice, that means that in theory that message could race to rabbit, get dispatched to a worker, and then do a SELECT against the database before the transaction is committed. Which would be Bad (
So, while this is absolutely fine, you'll need to change either the subscriber to trigger the job in a response callback.
In fact, we should probably trigger all AnnotationEvents inside response callbacks (being sure not to do so if the response is an error), so perhaps it would be better to do it once in h.api.views. This would ensure that:
AnnotationEventscan't modify annotations, as they don't have access to the session- they only get fired once the data is successfully written to the database
- errors in
AnnotationEventsubscribers don't cause the transaction to abort (which, given we've already got code to ensure this in one case, seems like the right thing to do)
nickstenning
Apr 25, 2016
Contributor
Ah, ok. This is a good idea, but you're going to need to be a bit careful if you do this. Because the view function is called inside a transaction, that means that you're going to be calling add_annotation.delay(id) while the transaction is still open.
While not likely in practice, that means that in theory that message could race to rabbit, get dispatched to a worker, and then do a SELECT against the database before the transaction is committed. Which would be Bad (
So, while this is absolutely fine, you'll need to change either the subscriber to trigger the job in a response callback.
In fact, we should probably trigger all AnnotationEvents inside response callbacks (being sure not to do so if the response is an error), so perhaps it would be better to do it once in h.api.views. This would ensure that:
AnnotationEventscan't modify annotations, as they don't have access to the session- they only get fired once the data is successfully written to the database
- errors in
AnnotationEventsubscribers don't cause the transaction to abort (which, given we've already got code to ensure this in one case, seems like the right thing to do)
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
nickstenning
Apr 25, 2016
Contributor
And yes, response callbacks are called after the transaction is committed (pyramid_tm is implemented as a tween).
nickstenning
Apr 25, 2016
Contributor
And yes, response callbacks are called after the transaction is committed (pyramid_tm is implemented as a tween).
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
chdorner
Apr 26, 2016
Contributor
Will work on this in a separate PR (#3250), and marking this PR as WIP until the other one is merged.
chdorner
Apr 26, 2016
•
Contributor
Will work on this in a separate PR (#3250), and marking this PR as WIP until the other one is merged.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
chdorner
May 4, 2016
Contributor
#3250 is now merged. I've rebased this branch and fixed a small issue due to the AnnotationEvent not containing the h.api.model.Annotation object anymore but the serialized version of an annotation. This is now ready for review again.
chdorner
May 4, 2016
Contributor
#3250 is now merged. I've rebased this branch and fixed a small issue due to the AnnotationEvent not containing the h.api.model.Annotation object anymore but the serialized version of an annotation. This is now ready for review again.
chdorner
added
the
WIP
label
Apr 26, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
chdorner
referenced this pull request
Apr 28, 2016
Closed
View and storage code for updating annotations in Postgres #3256
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
I've had a look over this as well, all looks good to me |
chdorner
added some commits
Apr 22, 2016
chdorner
removed
the
WIP
label
May 4, 2016
nickstenning
reviewed
May 4, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
nickstenning
May 4, 2016
Contributor
Ok, all good except we should be reindexing on update, too. I know the postgres code for update isn't done yet, but I think we should have the indexer responding to those events already otherwise we're going to forget it.
|
Ok, all good except we should be reindexing on update, too. I know the postgres code for update isn't done yet, but I think we should have the indexer responding to those events already otherwise we're going to forget it. |
chdorner
added some commits
Apr 22, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
chdorner
May 4, 2016
Contributor
Just addressed the last comments and also defined the celery and indexer queues in h.celery.
|
Just addressed the last comments and also defined the |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
LGTM. |
chdorner commentedApr 22, 2016
•
edited
This adds a new celery worker for syncing annotations created in Postgres to the new Elasticsearch index.
This PR depends on the merge of #3238, at which point the first commit needs to be removed (I just made sure that it doesn't raise an error, it isn't really fixing all the issues).
Update: #3238 is now merged, so this is ready to get merged as well.
This is now waiting for #3250 to be merged.
Update: #3250 is now merged.