---
title: "March, 2020"
date: 2020-03-02T12:31:30+02:00
author: "Alan Orth"
categories: ["Notes"]
---

## 2020-03-02

- Update [dspace-statistics-api](https://github.com/ilri/dspace-statistics-api) for DSpace 6+ UUIDs
  - Tag version 1.2.0 on GitHub
- Test migrating legacy Solr statistics to UUIDs with the as-of-yet unreleased [SolrUpgradePre6xStatistics.java](https://github.com/DSpace/DSpace/commit/184f2b2153479045fba6239342c63e7f8564b8b6#diff-0350ce2e13b28d5d61252b7a8f50a059)
  - You need to download this into the DSpace 6.x source and compile it

<!--more-->

```
$ export JAVA_OPTS="-Xmx1024m -Dfile.encoding=UTF-8"
$ ~/dspace63/bin/dspace solr-upgrade-statistics-6x
```

## 2020-03-03

- Skype with Peter and Abenet to discuss the CG Core survey
  - We also discussed some other CGSpace issues

## 2020-03-04

- Abenet asked me to add some new ILRI subjects to CGSpace
  - I [updated the input-forms.xml](https://github.com/ilri/DSpace/commit/b51a242e773bd8658d3cab4ac883975708b00386) in our `5_x-prod` branch on GitHub
  - Abenet said we are changing `HEALTH` to `HUMAN HEALTH` so I need to fix those using my `fix-metadata-values.py` script:

```
$ ./fix-metadata-values.py -i 2020-03-04-fix-1-ilri-subject.csv -db dspace -u dspace -p 'fuuu' -f cg.subject.ilri -m 203 -t correct -d
```

- But I have not run it on CGSpace yet because we want to ask Peter if he is sure about it...
- Send a message to Macaroni Bros to ask them about their Drupal module and its readiness for DSpace 6 UUIDs

## 2020-03-05

- I found a very [interesting comment on the Solr 8.1 guide](https://lucene.apache.org/solr/guide/8_1/solr-system-requirements.html#lucene-solr-prior-to-7-0) about Java compatibility:

> Lucene/Solr 7.0 was the first version that successfully passed our tests using Java 9 and higher. You should avoid Java 9 or later for Lucene/Solr 6.x or earlier.

## 2020-03-08

- I want to try to consolidate our yearly Solr statistics cores back into one `statistics` core using the solr-import-export-json tool
- I will try it on DSpace test, doing one year at a time:

```
$ ./run.sh -s http://localhost:8081/solr/statistics-2010 -a export -o /tmp/statistics-2010.json -k uid
$ ./run.sh -s http://localhost:8081/solr/statistics -a import -o /tmp/statistics-2010.json -k uid
$ curl -s "http://localhost:8081/solr/statistics-2010/update?softCommit=true" -H "Content-Type: text/xml" --data-binary "<delete><query>time:2010*</query></delete>"
$ ./run.sh -s http://localhost:8081/solr/statistics-2011 -a export -o /tmp/statistics-2011.json -k uid
$ ./run.sh -s http://localhost:8081/solr/statistics -a import -o /tmp/statistics-2011.json -k uid
$ curl -s "http://localhost:8081/solr/statistics-2011/update?softCommit=true" -H "Content-Type: text/xml" --data-binary "<delete><query>time:2011*</query></delete>"
$ ./run.sh -s http://localhost:8081/solr/statistics -a import -o /tmp/statistics-2012.json -k uid
$ curl -s 'http://localhost:8081/solr/statistics/select?q=time:2012*&rows=0&wt=json&indent=true' | grep numFound
  "response":{"numFound":3761989,"start":0,"docs":[]
$ curl -s 'http://localhost:8081/solr/statistics-2012/select?q=time:2012*&rows=0&wt=json&indent=true' | grep numFound
  "response":{"numFound":3761989,"start":0,"docs":[]
$ curl -s "http://localhost:8081/solr/statistics-2012/update?softCommit=true" -H "Content-Type: text/xml" --data-binary "<delete><query>time:2012*</query></delete>"
```

- I will do this for as many cores as I can (disk space limited) and then monitor the effect on the system and JVM memory usage
  - Exporting half years might work, using a filter query with months as a regular expression:

```
$ ./run.sh -s http://localhost:8081/solr/statistics-2014 -a export -o /tmp/statistics-2014-1.json -k uid -f 'time:/2014-0[1-6].*/'
```

<!-- vim: set sw=2 ts=2: -->