-
Notifications
You must be signed in to change notification settings - Fork 7
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
Refactor to straighten out language and improve dfe:analytics:check #30
Conversation
This gem doesn't care about models, it cares about entities. Reduce the points of contact with "model" language to a mapping method in the main namespace. See comment in README "All models are entities, but not all entities are models..." for rationale behind this change.
This now relies on the central list of entities we care about instead of building its own
It was possible for the analytics and analytics_blocklist files to get into a state where both files contained the same fields for the same entity. To eliminate ambiguity, detect these conflicts in dfe:analytics:check and prompt the user to regenerate the blocklist.
This causes some weird behaviour locally with inconsistent data ending up in the cache vs what's in a direct call to config_for, so take it out for now.
This is such a matter of taste
lib/dfe/analytics/fields.rb
Outdated
|
||
diff[:missing][entity] = missing_attributes if missing_attributes.any? | ||
|
||
diff[:surplus][entity] = surplus_attributes if surplus_attributes.any? |
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.
I found this bit a bit hard to digest. I think if you're going to be refactoring this bit, it would make sense to try to make it easier to comprehend, if possible. Maybe something like this (NB: untested code):
def self.entity_attributes_from_lists(entity, lists)
lists.map do |list|
# for each list of model attrs, look up the attrs for this model
list.fetch(entity, [])
end.reduce(:concat)
end
def self.entities_with_missing_attributes_from_lists(*lists)
DfE::Analytics.all_entities_in_application
.reduce({}) do |entities_missing_attributes, entity|
attributes_considered = entity_attributes_from_lists(entity, lists)
model = DfE::Analytics.model_for_entity(entity)
entities_missing_attributes[entity] = model.attribute_names - attributes_considered
entities_missing_attributes
end.reject { |_entity, attributes| attributes.empty? }
end
def self.entities_with_surplus_attributes_from_lists(*lists)
DfE::Analytics.all_entities_in_application
.reduce({}) do |entities_surplus_attributes, entity|
attributes_considered = entity_attributes_from_lists(entity, lists)
model = DfE::Analytics.model_for_entity(entity)
entities_surplus_attributes[entity] = attributes_considered - model.attribute_names
entities_surplus_attributes
end.reject { |_entity, attributes| attributes.empty? }
end
d96489f
to
287abaf
Compare
Only diff in one direction, vary argument order to change results. Easier to read (I hope!).
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.
Looks good! 🚢
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.
Argh. Wrong circle. 🤦
The useful
analytics:check
task detects when we add and remove fields from applications, but it had a shortcoming: it couldn't tell when a field existed in both the allowlist and the blocklist. This wasn't considered first time around because why would that ever happen. We now know that it does happen, and it happens when an entity wasn't previously in the allowlist but was in the blocklist (because we ignored it), and now we've added it to the allowlist (because we've decided not to ignore it) and now it's appearing in both.Not necessarily a problem, but it's unprofessional and confusing and it looks bad so it's no longer allowed 🚫 .
This PR also contains some refactoring to the README and methods which refer to the word
model
. We don't believe inmodels
out here; we believe inentities
. Keep usage ofmodel
andtable_name
to an absolute minimum so people don't get confused when we're referring to three somewhat equivalent things by three different names.🤔 You may notice that whilst this PR makes a point of saying that we send entity events rather than model events, the README still only talks about mixing the
Entities
behaviour into models. This is because the next PR is going to do away with the manual mixin altogether following very good idea from @misaka that we could do it automatically with information we've got lying around inDfE::Analytics
— progress continues on that here. This will fix a bug where we don't send updates for join tables without an associated model.This PR best reviewed commit by commit.