You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@jena.apache.org by GitBox <gi...@apache.org> on 2022/08/11 11:59:59 UTC
[GitHub] [jena] Aklakan opened a new issue, #1476: Assembler: Mode.DEFAULT / Mode.REUSE are not considered and result in Mode.CREATE
Aklakan opened a new issue, #1476:
URL: https://github.com/apache/jena/issues/1476
### Version
4.6.0-SNAPSHOT
### What happened?
While creating an assembler config that creates two services with different configurations over the same spatial dataset we noticed that the spatial index was unexpectedly loaded twice. The assembler framework documentation suggests that - by default - the same Java object created from an RDF resource should be reused wherever that RDF resource is referenced in the assembler spec.
However, in the code, the Mode flag is eventually ignored and always a fresh Java object is returned:
```java
public abstract class DatasetAssembler {
@Override
public Dataset open(Assembler a, Resource root, Mode mode) {
DatasetGraph dsg = createDataset(a, root) ;
return DatasetFactory.wrap(dsg);
}
}
```
I am not yet sure of the assembler life-cycle: Whether the cache of created objects would have to be an additional argument to the assembler, or whether it can be an attribute of the assembler.
### Relevant output and stacktrace
_No response_
### Are you interested in making a pull request?
Maybe
--
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: issues-unsubscribe@jena.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@jena.apache.org
For additional commands, e-mail: issues-help@jena.apache.org
[GitHub] [jena] Aklakan commented on issue #1476: Assembler: Mode.DEFAULT / Mode.REUSE are not considered and result in Mode.CREATE
Posted by GitBox <gi...@apache.org>.
Aklakan commented on issue #1476:
URL: https://github.com/apache/jena/issues/1476#issuecomment-1216407774
> Probably (it needs detailed analysis) the build policy should be "same URI, same thing" per build run which an individual builder can ignore.
The concept of the assembler is essentially the same as that of spring bean definitions which support different scopes:
https://docs.spring.io/spring-framework/docs/3.0.0.M3/reference/html/ch04s04.html
Scope | Description
-- | --
singleton | Scopes a single bean definition to a single object instance per Spring IoC container.
prototype | Scopes a single bean definition to any number of object instances.
In java this is done with
```java
class MyBeans {
@Bean
@Scope("prototype")
MyBean myBean() { ...}
}
```
Perhaps these annotations could be simply expressed in the RDF using an `ja:scope` attribute?
E.g.
```ttl
<#myMemoryDatasetBean> a ja:MemoryDataset ;
ja:scope ja:prototype ;
.
```
--
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: issues-unsubscribe@jena.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@jena.apache.org
For additional commands, e-mail: issues-help@jena.apache.org
[GitHub] [jena] afs commented on issue #1476: Assembler: Mode.DEFAULT / Mode.REUSE are not considered and result in Mode.CREATE
Posted by GitBox <gi...@apache.org>.
afs commented on issue #1476:
URL: https://github.com/apache/jena/issues/1476#issuecomment-1216480177
On the theme of prototype but making it context sensitive, not static either-or, and more RDF-y:
That concept can be extended with an intermediate:
```
<#fresh> a ja:NewInstance ;
ja:prototype <#description>;
.
```
i.e. the constructor for `ja:NewInstance` would make a `newItem` call to <#description> whereas direct use would make a `construct` call.
But we need Jena/Fuseki use cases first. Avoid over engineering!
--
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: issues-unsubscribe@jena.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@jena.apache.org
For additional commands, e-mail: issues-help@jena.apache.org
[GitHub] [jena] afs commented on issue #1476: Assembler: Mode.DEFAULT / Mode.REUSE are not considered and result in Mode.CREATE
Posted by GitBox <gi...@apache.org>.
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: issues-unsubscribe@jena.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@jena.apache.org
For additional commands, e-mail: issues-help@jena.apache.org