oh btw, let's say i retrieved a bean via a CONSTRUCT that does not retrieve its properties
You can also simply use a SELECT query - why do you need CONSTRUCT?
in my mental model, CONSTRUCT creates a graph of objects whereas a SELECT is more a table. so using a SELECT to build a graph of objects sounds unnatural to me.
Yes, you are right. The point is that KOMMA uses the underlying RDF store as "the graph" and not a subset that is extracted via construct (only for prefetching of bean properties as discussed before).
oh, btw, can i implement my own equals() and hashCode() on beans, via the behaviours? (that i call Support classes)
Yes, you can. But I would avoid this since KOMMA uses RDF's resources identity by comparing URIs or BNode IDs.
https://github.com/komma/komma/blob/master/bundles/core/net.enilink.komma.em/src/main/java/net/enilink/komma/em/internal/behaviours/EntitySupport.java#L74
Hi there,
i'm Fredy, currently working on https://linkedopenactors.org & https://www.iese.fraunhofer.de/de/innovation_trends/sra/smarte-landregionen.html.
I use rdf4j to handle rdf data in both projects. This weekend i was playing with komma and getting it running for writing/loading my loa organisations.
In loa i use a rdf4j httpRepo and maybe this is the problem of the really bad performance. I create and read a really small entity
(String addressCountry, String addressLocality, String addressRegion, String streetAddress, String postalCode) and it takes ~ 1 minute.
Is it possible in principle to use komma with http repos, or is this rather not a use case for komma.
btw. @kenwenzel thanks for your really fast answer!
@naturzukunft:matrix.org
Hello Fredy,
KOMMA normally uses lazy loading. This results in one query per bean for its RDF types and one query for each of its properties. The alternative is to use prefetching with construct queries.
You can find an example for this at https://github.com/numerateweb/numerateweb/blob/60154f1b543049695c3363f71736a7ee45571ae7/bundles/core/org.numerateweb.math/src/main/java/org/numerateweb/math/rdf/ObjectSupport.java#L21
Usually it is perfectly possible to use an HTTP repo but you have to reduce the overall number of queries (by prefetching and/or caching).
Maybe you can give some more explanations on your use case and the related SPARQL queries.
I have a lot of publications (CreativeWork) in a rdf repository that have the following structure:
https://linkedopenactors.org/specification/information_exchange_datamodel.html#information-exchange-data-model
This rdf repository is a clone of an existing database. It's just a RDF representation that also provide SPARQL.
There is a scheduled job that looks for changes in the main database and brings new publications or changes to publications into the rdf repository.
So every few minutes a variable number of publications (CreativeWork) are created or changed.
This here seems to be the biggest problem:
public void save(String subject, PostalAddressLoa postalAddressLoa) {
PostalAddressKomma created = entityManager.createNamed(URIs.createURI(subject),PostalAddressKomma.class);
created.setAddressCountry(postalAddressLoa.getAddressCountry());
created.setAddressLocality(postalAddressLoa.getAddressLocality());
created.setAddressRegion(postalAddressLoa.getAddressRegion());
created.setPostalCode(postalAddressLoa.getPostalCode());
created.setStreetAddress(postalAddressLoa.getStreetAddress());
}because each line seems to do a lot http things ?! Each setter takes ~ 10 sec.
I think there is another way to create objects, but haven't found it yet.
switching to 1.5.2 end in applicationContext errors while initialization.
I think version 1.4.0 uses eager change tracking leading to many HTTP requests as observed by you. This is fixed in version 1.5.2.
You can try:
DataChangeTracker changeTracker = injector.getInstance(DataChangeTracker.class);
changeTracker.setEnabled(null, false);Use the code above once before executing any modifications with an entity manager.
The enabled state of the change tracker is a thread-local.
1 reply
In the moment one of our node seems to lock the repo directory and the other node fails.
The same problem would we have using komma.
we was using memory store, but changed to native store. Same problem with both.
i got confused by the "The Repository API supports multithreaded access" statement because i assumed there were threads on several nodes.
Cool!
BTW, to speed up the retrieval of the bean at this line
you can replace em.find(...) by something like:
em.createQuery("construct { ?s a <komma:Result> ; ?p ?o } where { ?s ?p ?o }").setParameter("s", uri).getSingleResult(PostalAddressKomma.class);