...
Tested by | Platform | Container (Tomcat/Jetty) | Database Backend | From Fedora | To Fedora | Number of RDF Resources | Number of Binaries | Size of Backup (du -h .) | Success? | Notes |
---|---|---|---|---|---|---|---|---|---|---|
Linux | Jetty | File-simple | 4.7.5 | 4.7.5 | 100 | |||||
Linux | Tomcat | Postgres | 4.7.1 | 4.7.5 | 6400 | 6400 | 6.7 G | Performed a GET test on all resources in 4.7.5 before /fcr:restore, thereby mimicking an 'in place upgrade.' All succeeded. | ||
Linux | Tomcat | Postgres | 4.7.3 | 4.7.5 | 6400 | 6400 | 6.7 G | Performed a GET test on all resources in 4.7.5 before /fcr:restore, thereby mimicking an 'in place upgrade.' All succeeded. | ||
Linux | Tomcat | Postgres | 4.7.4 | 4.7.5 | 6400 | 6400 | 6.7 G | Performed a GET test on all resources in 4.7.5 before /fcr:restore, thereby mimicking an 'in place upgrade.' All succeeded. | ||
Linux | Tomcat | Mysql | 4.7.4 | 4.7.5-RC-1 | 79456 | 11969 | 96G | Performed an fcr:export from 4.7.4. Performed an fcr:import to 4.7.5-RC-1. Performed a reindex using camel (to walk all RDF resources). I did not test every binary. |
NB: "Success" is measured not by receiving a "204 No Content" message after the 'fcr:restore' command, but by performing a GET on every resource in the repository and receiving "200 OK" messages.
...