alanorth
/
dspace-statistics-api
mirror of https://github.com/ilri/dspace-statistics-api.git
1
0
Fork 0
Code Releases Activity
dspace-statistics-api/app.py

45 lines
1.2 KiB
Python
Raw Normal View History

Initial commit Add first working version of the statistics API.
2018-09-18 13:03:15 +02:00
# Tested with Python 3.6
# See DSpace Solr docs for tips about parameters
# https://wiki.duraspace.org/display/DSPACE/Solr
Refactor configuration into separate module There is a good example of this in the Project Weekend GitHub profile. See: https://github.com/projectweekend/Falcon-PostgreSQL-API-Seed
2018-09-18 15:59:28 +02:00
from config import SOLR_SERVER
from config import SOLR_CORE
Initial commit Add first working version of the statistics API.
2018-09-18 13:03:15 +02:00
import falcon
from SolrClient import SolrClient
class ItemResource:
def on_get(self, req, resp):
"""Handles GET requests"""
# Return HTTPBadRequest if id parameter is not present and valid
item_id = req.get_param_as_int("id", required=True, min=0)
Refactor configuration into separate module There is a good example of this in the Project Weekend GitHub profile. See: https://github.com/projectweekend/Falcon-PostgreSQL-API-Seed
2018-09-18 15:59:28 +02:00
solr = SolrClient(SOLR_SERVER)
Initial commit Add first working version of the statistics API.
2018-09-18 13:03:15 +02:00
# Get views
Refactor configuration into separate module There is a good example of this in the Project Weekend GitHub profile. See: https://github.com/projectweekend/Falcon-PostgreSQL-API-Seed
2018-09-18 15:59:28 +02:00
res = solr.query(SOLR_CORE, {
app.py: Fix Solr queries for item views According to dspace-api's Constants.java, items are type 2 and they use a unique ID field of `id` instead of `owningItem`. There is no need to check the bundleName for item types. Also, I decided to use the main Solr query for item IDs because the filter query parameter (fq) stores results in the filterCache and can be quite expensive with cores storing tens of millions of docu- ments (we currently have 149 million docs!). It makes sense to use the filter query parameter to reduce the result set returned by the main Solr query.
2018-09-20 16:34:55 +02:00
'q':'type:2 AND id:{0}'.format(item_id),
'fq':'isBot:false AND statistics_type:view'
app.py: Use SolrClient's rows parameter Instead of putting this in the raw query we can just use SolrClient's native rows parameter.
2018-09-19 11:48:28 +02:00
}, rows=0)
Initial commit Add first working version of the statistics API.
2018-09-18 13:03:15 +02:00
views = res.get_num_found()
# Get downloads
Refactor configuration into separate module There is a good example of this in the Project Weekend GitHub profile. See: https://github.com/projectweekend/Falcon-PostgreSQL-API-Seed
2018-09-18 15:59:28 +02:00
res = solr.query(SOLR_CORE, {
app.py: Fix Solr queries for item views According to dspace-api's Constants.java, items are type 2 and they use a unique ID field of `id` instead of `owningItem`. There is no need to check the bundleName for item types. Also, I decided to use the main Solr query for item IDs because the filter query parameter (fq) stores results in the filterCache and can be quite expensive with cores storing tens of millions of docu- ments (we currently have 149 million docs!). It makes sense to use the filter query parameter to reduce the result set returned by the main Solr query.
2018-09-20 16:34:55 +02:00
'q':'type:0 AND owningItem:{0}'.format(item_id),
'fq':'isBot:false AND statistics_type:view AND bundleName:ORIGINAL'
app.py: Use SolrClient's rows parameter Instead of putting this in the raw query we can just use SolrClient's native rows parameter.
2018-09-19 11:48:28 +02:00
}, rows=0)
Initial commit Add first working version of the statistics API.
2018-09-18 13:03:15 +02:00
downloads = res.get_num_found()
statistics = {
'id': item_id,
'views': views,
'downloads': downloads
}
resp.media = statistics
api = falcon.API()
api.add_route('/item', ItemResource())