Releases: kbss-cvut/jopa
Releases · kbss-cvut/jopa
2.6.1
- Experimental implementation of optimized entity retrieval from query results (Enhancement #357).
- Enabled on entity manager/entity manager factory level using the
cz.cvut.kbss.jopa.experimental.query.enableEntityLoadingOptimizer
property (see theJOPAExperimentalProperties
class). - Works only for typed queries selecting an entity — they project a single variable, and the query result type is an
entity type. - The optimization adds a triple pattern
?x ?y ?z
into the query, selecting all property values for the given
subject, the query projection is then modified to?x ?y ?z
. Query result rows are transformed to axioms and an
entity is reconstructed from them. - Works for plural attributes as well - result rows are grouped until a single entity can be reconstructed from
them. - This optimization should reduce the number of repository calls. A single query execution will be able to load the
resulting entities (previously, each entity was loaded separately after the query execution). That is, if the query returnsn
results, the previous implementation would maken + 1
repository calls to load the entities. The new implementation will make just1
call. Note that references (i.e., relationship traversal) are still loaded by separate repository calls. - Current limitations:
- Optimization is not applied if offset or limit are set on the query
- Optimization is not applied if the query results are retrieved as a stream (
Query.getResultStream
) - Descriptor provided to the query is not applied to the entity loading - entity is reconstructed directly from
query results.
- If an IC violation is thrown (because the query does not differentiate asserted and inferred data), the entity is
loaded using the usual mechanism which separates asserted and inferred data. - Since JOPA now uses a grammar-based SPARQL parser, it is stricter when handling queries. This brings the following
potential breaking changes:- Positional parameters without a position number are not supported anymore (e.g.,
SELECT ?x WHERE { ?x a $ }
must be changed toSELECT ?x WHERE { ?x a $1 }
). On the other hand, the same positional parameter (same
position number) can now be used multiple times in a query. - Parameters cannot be used in IRI string anymore, i.e.,
<http://example.com/?1>
will not work
- Positional parameters without a position number are not supported anymore (e.g.,
- Enabled on entity manager/entity manager factory level using the
- Dependency updates: RDF4J 5.1.6.
2.6.0
2.5.1
2.5.0
- Support
IRI
as Query parameters (Enhancement #354). - Add entity class IRI to the static metamodel (Enhancement #360).
- Implement a plugin API - currently there is plugin for the whole persistence unit lifecycle (Enhancement #361).
- Support generating Java
URI
constants into theVocabulary
file in OWL2Java. - Make static metamodel generator a service discoverable using the Java Service Provider Interface.
2.4.4
2.4.3
2.4.2
2.4.1
2.4.0
- Add support for a read-only
EntityManager
which will can be used to optimize read-only transactions (Feature #84, docs). - Add support for static repository context declaration using the
@Context
annotation (Feature #104, docs). - Implement
includeExplicit
attribute of@Inferred
- it is now possible to exclude explicit (asserted) values from attribute (Enhancement #190). - Add support for an in-memory OWLAPI storage (Enhancement #330, docs).
- Dependency updates: Jena 5.4.0, RDF4J 5.1.3.