Recently, we ran into a problem where one of our workflows was inadvertently creating RELS-EXT datastreams as Managed content in a 3.2.1 repository. Here's how it happened:
1) The objects were created by empty POST to /objects/new:pid. Apparently, the "create a new 'empty' object" facility available by that means does _not_ create a RELS-EXT datastream. 2) Then externally-generated complete RELS-EXT was POSTed to /objects/new:pid/datastreams/RELS-EXT?controlGroup=M This was an bad workflow engineering on our part, but it points up the fact that (unless my diagnosis is very wrong) there is no validation occurring in that situation. The objects in question went merrily on their way and we only discovered the problem when trying to purge a few. The objects were purged from the repo, but the Resource Index did not successfully purge the associated triples. We're not yet sure whether the purges from the repo were entirely clean. What's more, it turned out to be impossible to update RELS-EXT on those objects before they were purged. We didn't try the same trick with DC because DC _is_ automatically created by a POST to /objects/new. Is this worthy of a Jira issue to get a fix into place for pre-3.4 3-series repos? Our solution is going to be to upgrade to 3.4, which was always our intent anyway, but that may not suffice for some folk. The mistaken API call could either be rejected or transparently converted into the creation of an inline datastream. I'm not sure which is better. --- A. Soroka Digital Research and Scholarship R & D and Online Library Environment the University of Virginia Library ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Fedora-commons-users mailing list Fedora-commons-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
