Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

DatabasePlatformTested bySuccess RC1?Success RC2?Notes
MySQL osx

(tick)

(tick)


Danny Bernstein: (error)Restoring v1 after creating v2 does not seem to work:

Steps to reproduce: 1. Create a binary with fileA.jpg

2. Create version v1.

3. Update binary with fileB.jpg

4. Create version v2.

5. Click on versions link and click on v1 link.

6. Click "Revert to this Version"

7. Return to binary resource metadata page. Notice the file associated with the version fileB.jpg rather than the expected fileA.jpg. It does not appear that the version was reverted.

Joshua Westgard: Hey Danny Bernstein, when I tested the versioning I was just making changes to metadata not binaries and didn't notice any problems; after seeing your note, however, I tried with a binary and did notice that the browser cached the previous version, so after restoring it was still displaying the previous data, but upon refreshing the resource page the restored version was visible as expected. Any chance this is the same problem you were seeing?

Joshua Westgard: could be, though I thought I did a hard refresh. I'll try it again to conf hirm.

Joshua Westgard: I must not have done a hard refresh. So yes after a hard refresh it worked. I wonder if it should be a logged as a bug nevertheless. Ideally any refresh would not be required at all. A Command-R refresh doesn't refresh the page. Only Command-Shift-R. It seems like it could be a source of confusion. Perhaps a JIRA is warranted.


PostgreSQLosxJoshua Westgardconfig successful; testing in progress

PostgreSQL linuxKevin Ford


Tests were performed against fcrepo-webapp-4.7.5-RC-1 not fcrepo-webapp-plus-4.7.5-RC-1.  

MySQL5.6 linuxKevin Ford


Tests were performed against fcrepo-webapp-4.7.5-RC-1 not fcrepo-webapp-plus-4.7.5-RC-1.  

PostgreSQL linuxKevin Ford


Tests were performed against fcrepo-webapp-plus-4.7.5-RC-1.  

MySQL5.6 linuxKevin Ford


Tests were performed against fcrepo-webapp-plus-4.7.5-RC-1.  

fcr:backup/fcr:restore Functionality

...

Tested by

Platform

Container

(Tomcat/Jetty)

Database

Backend

From Fedora
Version

To Fedora 
Version

Number of

RDF Resources

Number of

Binaries

Size of Backup (du -h .)

Success?

Notes                  


LinuxJettyFile-simple4.7.54.7.5
100


LinuxTomcatPostgres4.7.14.7.5-RC-1640064006.7 G(tick)Performed a GET test on all resources in 4.7.5 before /fcr:restore, thereby mimicking an 'in place upgrade.'  All succeeded.
LinuxTomcatPostgres4.7.34.7.5-RC-1640064006.7 G(tick)Performed a GET test on all resources in 4.7.5 before /fcr:restore, thereby mimicking an 'in place upgrade.'  All succeeded.
LinuxTomcatPostgres4.7.44.7.5-RC-1640064006.7 G(tick)Performed a GET test on all resources in 4.7.5 before /fcr:restore, thereby mimicking an 'in place upgrade.'  All succeeded.
LinuxTomcatMysql4.7.44.7.5-RC-1794561196996G(tick)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.
LinuxTomcatMysql 5.64.7.54.7.5-RC-1640064006.7 G(tick)
LinuxTomcatPostgres4.7.54.7.5-RC-1640064006.7 G(tick)Back up actually created from a mysql backend repo.

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. 

...