afs commented on issue #1476:
URL: https://github.com/apache/jena/issues/1476#issuecomment-1216248026
Simpler example: two references to an in-memory dataset. This always cause
two databases.
```
:service1 rdf:type fuseki:Service ;
fuseki:name "first" ;
fuseki:dataset :dataset ;
.
:service2 rdf:type fuseki:Service ;
fuseki:name "second" ;
fuseki:dataset :dataset ;
.
:dataset rdf:type ja:MemoryDataset ;
.
```
but
```
:dataset rdf:type tdb2:DatasetTDB2 ;
tdb2:location "DB2" ;
.
```
is one database because TDB manages instances itself (it has to anyway)
using the location as a key.
Dealing with shared/fresh via `Mode` does not work. In the first example,
should it be one database or two? Either may have been intended.
The assembler design implicitly assumes use-once assemblers (but that is a
contradiction to the registry) and use on a single thread.
* There needs to be a scope object passed around.
* The needs to be a better policy for same vs fresh.
The assembler subsystem needs replacing, new API and simplified.
Realistically, that means new "thing builder", with new API and new algorithm.
Fuseki is the main user nowadays and that ought to be the primary use case.
A Fuseki service is not assembled, it's specific code to process that
description; the dataset of the service is an assembler build.
Probably (it needs detailed analysis) the build policy should be "same URI,
same thing" per build run which an individual builder can ignore. Something
like
```
interface Constructor<X> {
public default <X> construct<X>(BuildContext cxt, Graph
descriptionGraph, Node description) {
cxt.computeIfAbsent(description, (d)->newItem(cxt,
descriptionGraph, d));
}
public <X> newItem<X>(BuildContext cxt, Graph descriptionGraph, Node
description) { return null; }
}
```
but before code, we need to scope this with use cases and asking what use if
made of existing assemblers outside of Fuseki.
The new process would be able to call existing assemblers via
`Assembler.general`, (so supports all legacy, including legacy configurations
in the field). It should on graph/node not Resource.
The good news is that building services in Fuseki is located in one area of
code and also that the core of build-dispatch isn't that large.
tl;dr: design first!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
