-
Notifications
You must be signed in to change notification settings - Fork 292
Simplify Eventgen #6188
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
Simplify Eventgen #6188
Conversation
Precompute a table of object names for which events should be propagated. This avoids the list querying done every time the database queues an event. Signed-off-by: Colin James <colin.barr@cloud.com>
Signed-off-by: Colin James <colin.barr@cloud.com>
It's worth noting that I'm unsure of how solid |
Signed-off-by: Colin James <colin.barr@cloud.com>
Signed-off-by: Colin James <colin.barr@cloud.com>
Signed-off-by: Colin James <colin.barr@cloud.com>
Signed-off-by: Colin James <colin.barr@cloud.com>
To avoid recomputing the symmetric closure several times during module initialisation for Eventgen, we introduce a hashtable that stores the relation. Signed-off-by: Colin James <colin.barr@cloud.com>
39ffcb6
to
d622dd8
Compare
(object, field) *) | ||
relate p p' ; relate p' p | ||
in | ||
Dm_api.relations_of_api api |> List.iter close ; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we log the size of this table to get an idea?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should comprise twice as many entries as is in Datamodel.all_relations
- which is few in the great scheme of things. I think it's unimportant in the grand scheme of things - the old code was fine as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes make the Eventgen module a lot easier to read. And reviewing this PR was a good opportunity to actually learn and understand what it does!
I can't help but think that all this relation checking is unnecessarily duplicated between the database itself and the event system. As the database automatically updates the fields for the "other" side of relations, why can't it call the event callback for each of those?
This is a small effort to simplify the code within the
Eventgen
module. The previous style is very unwieldy and makes the file appear more complicated on the surface than it really is.Passes BVT+BST (209475) but would appreciate review comments as I've dropped the potential for stdout logging in some places (easy to add back) and added commentary that may not be fully accurate.