Skip to content
This repository has been archived by the owner on Apr 11, 2022. It is now read-only.

Moved analytics configuration to the database. #551

Merged
merged 7 commits into from
Jun 28, 2017
Merged

Conversation

aslagle
Copy link
Collaborator

@aslagle aslagle commented Jun 27, 2017

This branch moves the analytics configuration into an ExternalIntegration, and changes Analytics so its no longer a global singleton. It also defines the constants for LocalAnalyticsProvider to be configured in the admin interface.

@@ -978,11 +979,13 @@ def apply(self, _db, collection, replace=None):
if pool and self._availability_needs_update(pool):
# Update availabily information. This may result in
# the issuance of additional circulation events.
analytics = Analytics(_db)
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like this, but I'm not sure anything else would be better.

Copy link
Contributor

@leonardr leonardr Jun 27, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this is a performance problem. We're looking at database queries and module imports every time we want to change a LicensePool. I think analytics should be passed into ReplacementPolicy just like mirror is. That should cut down on the number of times we have to instantiate a new Analytics object.

@aslagle
Copy link
Collaborator Author

aslagle commented Jun 27, 2017

Also added in two sitewide settings that weren't in the admin interface yet.

analytics.py Outdated
@@ -30,5 +37,5 @@ def __init__(self, _db):
def collect_event(self, library, license_pool, event_type, time=None, **kwargs):
if not time:
time = datetime.datetime.utcnow()
for provider in self.providers:
for provider in (self.sitewide_providers + self.library_providers[library.id]):
Copy link
Contributor

@leonardr leonardr Jun 28, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When you call collect_event() several times to trigger the same event for multiple libraries, will this cause the event to be collected once for each sitewide provider?

If so, it might work better for the sitewide providers to be handled as providers that, if enabled, are presumed to be enabled for every library in the system. The event still happens multiple times, but it's recorded as happening in each relevant library.

Or maybe it doesn't matter much because the circulationevents table doesn't record the library ID, only the license pool ID, so collecting an several times will do the same thing as collecting it once.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point. If there's a collection with multiple libraries it will cause duplicate events in the sitewide provider. I was thinking that I'd have to add the library id to the CirculationEvents table and the Google Analytics setup in a future pr though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding library ID to CirculationEvents makes a lot of sense. File a bug for that and then 👍

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aslagle aslagle merged commit 7e14ffe into multi-tenant Jun 28, 2017
@aslagle aslagle deleted the analytics-in-db branch June 28, 2017 20:37
@aslagle aslagle removed the in review label Jun 28, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants