Two options that come to mind (maybe neither is good, but maybe one is okay):
1) Logging a missing/failed source at ERROR level. I don't like this much, for the same reasons Rob doesn't like Laura's first suggestion.
2) Config it. Default setting is fail out on a missing/failed source, just as now. But provide an alternative "Expect weird data (un)availability" setting. This could be a property on the dataset assembler entity, e.g. ja:failFast or something.
(2) seems reasonable to me, although I admit I have no use cases and can't think of any that I wouldn't rather solve in a more deterministic way, for example using some kind of templating action as Andy suggests. One of the cool things about the assembler tech is that assemblers are RDF: it's sort of homoiconic-ish. Maybe more ish than homoiconic. :)
ajs6f Rob Vesse wrote on 10/20/17 5:17 AM:
While that is a simple change it is a breaking change behaviourally. You go from a situation where a user gets an explicit error message that they can do something about to a situation where some aspects of invalid configurations are silently ignored. For complex configurations this may lead to all sorts of subtle and invisible errors which uses could waste far more time trying to track down than if they had just received an error as they do currently. Rob On 20/10/2017 07:07, "Laura Morales" <[email protected]> wrote: The problem is here: https://github.com/apache/jena/blob/cc038809fb622779933831011909714e22ef494c/jena-arq/src/main/java/org/apache/jena/sparql/core/assembler/DatasetAssembler.java#L79 This is a for() loop reading all the RDFNode in the configuration file. The "gName" variable corresponds to the "namedGraph" setting, and the "g" variable to the "graph" setting. When the execution reaches line #79 Model m = a.openModel(g); this (I guess) calls the "open" method overridden by hdt-java open(). So, if I return null, "Model m" will be null which is probably causing problems with the next line, ds.addNamedModel(gName, m); I think this should be the correct behavior instead: Model m = a.openModel(g); if (m != null) ds.addNamedModel(gName, m); it's just 1 additional line :) This way, if the custom assembler returned ModelFactory.createModelForGraph(null) or return ModelFactory.createDefaultModel(), Fuseki will create a new but empty graph in the dataset. If instead the custom assembler open() function returns null, the model is not added at all. What do you think? I haven't tried this because I don't know how to compile Jena/Fuseki, but I'm confident that it should work. Could somebody who knows how to compile Jena try this? Thanks! Subject: Re: Fuseki+HDT graceful "File not found" > I've put a check here, in the "open" function: > > if(!new File(file).isFile()) > return null; In the file HDTGraphAssembler.java, adding these lines before the try..catch block seems to work, more or less... if (!new File (file).isFile ()) return ModelFactory.createModelForGraph (null); I've tried this, and it looks like it creates an empty graph. That is, I find the new graph in the dataset, but it's empty, no triples. I don't know if or how it's possible to skip the entire graph entirely, such that not even an empty graph is added to the dataset.
