alanorth/cgspace-notes
1
0
Fork 0
mirror of https://github.com/alanorth/cgspace-notes.git synced 2025-01-27 05:49:12 +01:00
Code Issues Projects Releases Wiki Activity

Update notes for 2020-04-13

Browse Source
This commit is contained in:
Alan Orth
2020-04-13 17:24:05 +03:00
parent 246538db59
commit 3fab0c20e2
34 changed files with 184 additions and 125 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
content/posts/2020-04.md
View File

@ -119,4 +119,36 @@ $ ~/dspace63/bin/dspace solr-upgrade-statistics-6x
- More work on the DSpace 6.3 stuff, improving the GDPR consent logic to use [haven](https://github.com/chiiya/haven) instead of cookieconsent
- It works better by injecting the Google Analytics script after the user clicks agree, and it also has a preferences section that gets automatically injected on the privacy page!
## 2020-04-13
- I realized that `solr-upgrade-statistics-6x` only processes 100,000 records by default so I think we actually need to finish running it for all legacy Solr records before asking Atmire why CUA statlets and detailed statistics aren't working
- For now I am just doing 250,000 records at a time on my local environment:
```
$ export JAVA_OPTS="-Xmx2000m -Dfile.encoding=UTF-8"
$ ~/dspace63/bin/dspace solr-upgrade-statistics-6x -n 250000
```
- Despite running the migration for all of my local 1.5 million Solr records, I still see a few hundred thousand like `-1` and `0-unmigrated`
- I will purge them all and try to import only a subset...
- After importing again I see there are indeed tens of thousands of these documents with IDs "-1" and "0"
- They are all `type: 5`, which is "SITE" according to `Constants.java`:
```
/** DSpace site type */
public static final int SITE = 5;
```
- Even after deleting those documents and re-running `solr-upgrade-statistics-6x` I still get the UUID errors when using CUA and the statlets
- I have sent some feedback and questions to Atmire (including about the  issue with glypicons in the header trail)
- In other news, my local Artifactory container stopped working for some reason so I re-created it and it seems some things have changed upstream (port 8082 for web UI?):
```
$ podman rm artifactory
$ podman pull docker.bintray.io/jfrog/artifactory-oss:latest
$ podman create --ulimit nofile=32000:32000 --name artifactory -v artifactory_data:/var/opt/jfrog/artifactory -p 8081-8082:8081-8082 docker.bintray.io/jfrog/artifactory-oss
$ podman start artifactory
```
<!-- vim: set sw=2 ts=2: -->