So, this is (so far) a purely hypothetical question - but let’s say that Nexus (3.x) for some reason can’t be started, and that you have a whole team of developers (and their nervous manager) who are urgent to make a production hotfix deploy of com.bar.foo:example:123:jar.
With Nexus 2.x you could have fetched the jar file from the com/bar/foo/example/123 directory, but how would you quickly find this specific jar file in a 50TB S3 bucket that contains the blob store files created by Nexus3?
The blob store’s index is held inside NXRM’s embedded Orient database, so if for some reason you can’t start NXRM 3, you could use a standalone Orient client .jar to connect to the embedded database. (Or a recent backup of it, if your hypothetical NXRM 3 instance is damaged.)
Alternately, you can look in the properties files that are stored alongside the blobs—these hold the repository name and coordinates in case of a restore-from-blobs scenario. Accessing these probably isn’t quick for a 50 TB blob store, however.
I don’t advise ever updating the blobs outside of NXRM 3, however, as that will confuse NXRM when it eventually gets up and running.
@mprescott Thanks, that was however what I feared. After reading various reports of corrupted Orient databases, I concluded that the Nexus2 way of storing artifacts is a better solution for mission critical operation: regardless of whether Nexus2 is running or not, you’ll always be able to find com/somecompany/urgentlyneededfile/123 by just navigating to that location in the file system.
The NXRM 3 storage approach might be optimized for GUI searches, but it seems like it introduces a risk in mission critical situations when Nexus for some reason doesn’t start due to a corrupted DB
