Unhandled model references

[rleigh-codelibre]

With a current build, I'm seeing lots of this type of warning/error:

[warning] Unable to handle reference of type: St10shared_ptrIN3ome3xml5model9ReferenceEE

That's std::shared_ptr<ome::xml::model::Reference> in English.

That's indicative of something wrong in the model code, or invalid input. The former is most likely. Either way, it's something which should be investigated and fixed. Has there been a change to the model without a corresponding update to the C++ model code or templates?

[rleigh-codelibre]

% grep Unable typescript  | sed -e 's;.*\[warning\];;' | sort | uniq -c
     36  LightSource: Unable to handle reference of type: St10shared_ptrIN3ome3xml5model9ReferenceEE
    300  ManufacturerSpec: Unable to handle reference of type: St10shared_ptrIN3ome3xml5model9ReferenceEE

In all cases this is a result of Target::link() returning false. So it's being passed an invalid type of reference, or there's a bug.

The unhandled references are seen with many of the reference samples from ome-model:

ModelVariants/ModelTest.CreateMetadataFromFile/4 uses share/ome/xml/samples/2010-04/filter.ome.xml from ome-model
ModelVariants/ModelTest.CreateMetadataFromFile/13 uses share/ome/xml/samples/2010-04/instrument.ome.xml from ome-model
ModelVariants/ModelTest.CreateMetadataFromFile/17 uses share/ome/xml/samples/2012-06/filter.ome.xml from ome-model
ModelVariants/ModelTest.CreateMetadataFromFile/26 uses share/ome/xml/samples/2012-06/instrument.ome.xml from ome-model
ModelVariants/ModelTest.CreateMetadataFromFile/47 uses share/ome/xml/samples/2013-06/filter.ome.xml from ome-model
ModelVariants/ModelTest.CreateMetadataFromFile/52 uses share/ome/xml/samples/2013-06/instrument.ome.xml from ome-model
ModelVariants/ModelTest.CreateMetadataFromFile/58 uses share/ome/xml/samples/2011-06/instrument.ome.xml from ome-model
ModelVariants/ModelTest.CreateMetadataFromFile/60 uses share/ome/xml/samples/2011-06/filter.ome.xml from ome-model
ModelVariants/ModelTest.CreateMetadataFromFile/76 uses share/ome/xml/samples/2010-06/filter.ome.xml from ome-model
ModelVariants/ModelTest.CreateMetadataFromFile/90 uses share/ome/xml/samples/2010-06/instrument.ome.xml from ome-model
ModelVariants/ModelTest.CreateMetadataFromFile/110 uses share/ome/xml/samples/2009-09/instrument.ome.xml from ome-model
ModelVariants/ModelTest.CreateMetadataFromFile/122 uses share/ome/xml/samples/2015-01/instrument-units-alternate.ome.xml from ome-model
ModelVariants/ModelTest.CreateMetadataFromFile/124 uses share/ome/xml/samples/2015-01/instrument.ome.xml from ome-model
ModelVariants/ModelTest.CreateMetadataFromFile/127 uses share/ome/xml/samples/2015-01/instrument-units-default.ome.xml from ome-model
ModelVariants/ModelTest.CreateMetadataFromFile/137 uses share/ome/xml/samples/2015-01/filter.ome.xml from ome-model
ModelVariants/ModelTest.CreateMetadataFromFile/158 uses share/ome/xml/samples/2016-06/instrument-units-default.ome.xml from ome-model
ModelVariants/ModelTest.CreateMetaexamples/metadata-formatwriter2dataFromFile/159 uses share/ome/xml/samples/2016-06/instrument.ome.xml from ome-model
ModelVariants/ModelTest.CreateMetadataFromFile/161 uses share/ome/xml/samples/2016-06/filter.ome.xml from ome-model
ModelVariants/ModelTest.CreateMetadataFromFile/167 uses share/ome/xml/samples/2016-06/instrument-units-alternate.ome.xml from ome-model

ModelVariants/ModelTest.CreateMetadataFromStream repeats the same warnings
ModelVariants/ModelTest.CreateMetadataFromString repeats the same warnings

So these are all containing an error propagated through many model revisions (possible), or there's a code bug. I'm uncertain that the Java tests comprehensively test these like the C++ tests.

And it's also seen in these two tests which fill the metadata store by hand:

examples/metadata-formatwriter
examples/metadata-formatwriter2

I'd suggest starting by looking at metadata-formatwriter. It's self-contained, doesn't use transforms, and there are only three calls to set*Ref. And only one of those involves ManufacturerSpec (store->setDetectorAnnotationRef).

Assuming this is a real bug, it's a fairly critical functionality limitation for OME Files if the store is failing to link annotations.

[rleigh-codelibre]

With some extra logging:

     36  LightSource (Laser): Unable to handle reference of type: PN3ome3xml5model9ReferenceE for Arc
      9  ManufacturerSpec (Detector): Unable to handle reference of type: PN3ome3xml5model9ReferenceE for MapAnnotation
     57  ManufacturerSpec (FilterSet): Unable to handle reference of type: PN3ome3xml5model9ReferenceE for Dichroic
    198  ManufacturerSpec (FilterSet): Unable to handle reference of type: PN3ome3xml5model9ReferenceE for Filter
     36  ManufacturerSpec (Laser): Unable to handle reference of type: PN3ome3xml5model9ReferenceE for Arc

[rleigh-codelibre]

@joshmoore Should be fixed by ome/ome-model#81 While for Java this is fixing bogus warnings, for C++ it's fixing some fundamental brokenness in reference processing. As such, I think making an ome-model patch release with these fixes would be warranted. If we could include ome/ome-model#65 and the other build updates as well, that would be very helpful.

Particularly with people starting to do serious work on top of OME Files, having this stuff working and in a release in the near future would be greatly desirable.