Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    kenwenzel
    @kenwenzel
    Welcome to the KOMMA gitter group.
    lolive
    @lolive
    hello
    kenwenzel
    @kenwenzel
    Hello. Maybe it is easier to continue a general discussion here.
    As already described here komma/komma#21 detaching beans is currently not fully supported by KOMMA. Maybe I can help if you describe your usage scenario a bit further.
    lolive
    @lolive
    i am evaluating komma at the moment. so no real use case.
    the question is how to transfert beans to the service layer of a J2EE app
    i want those beans to be detached
    so i suppose i have to use a DTO to suck the data out of the entity beans into business POJO
    not a big deal, just a point i need to know
    oh btw, let's say i retrieved a bean via a CONSTRUCT that does not retrieve its properties
    lolive
    @lolive
    will a em.refresh(myBean) automatically fill all those properties for me?
    kenwenzel
    @kenwenzel
    Basically em.refresh(myBean) just invalidates all cached data for the bean properties. After using this method any call to a mapped method like myBean.getXYZ() triggers a SPARQL query against the underlying RDF store. You have two choices: Either you use a CONSTRUCT query with "?s ?p ?o" to fetch all possible properties of the bean (even more as those that may be mapped) or you inspect the beans methods via reflection, get the mapped properties and then create a specific construct query for this bean. (BTW, manually refreshing a bean is almost never required with KOMMA since it uses its own mechanisms to track changes and invalidate the caches. But if you change the RDF store from outside then it may be required to call the refresh methods on your own.)
    Another question: Why do you want to use DTOs? You can just pass the "real" beans to the service layer...
    kenwenzel
    @kenwenzel

    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?

    lolive
    @lolive
    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.
    oh, btw, can i implement my own equals() and hashCode() on beans, via the behaviours? (that i call Support classes)
    lolive
    @lolive
    Oh, and DTOs make the service layer to be independant of the lower layers. for example you avoid sending of massive and unexpected SELECTs to the DB.
    1 reply
    kenwenzel
    @kenwenzel

    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.

    lolive
    @lolive
    ok, but when i need to add beans to a map for example. i need to have those methods implemented
    kenwenzel
    @kenwenzel
    Those methods are already implemented in EntitySupport (base behaviour that is added to all beans of an entity manager):
    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
    lolive
    @lolive
    Ok.
    My concern now is about your statement about "the graph"
    I have a unit test that might fail because of that
    I will investigate that a little bit and come back to you later in the afternoon, if you are ok
    kenwenzel
    @kenwenzel
    Yes, that's OK.
    lolive
    @lolive
    a behaviour must implement BOTH a bean interface and Behaviour<beanInterface>? that sounds overkill, no? just Behaviour<beanInterface> would be enough, no?
    or you want to have the @Override annotation to work when coding the override a bean's method?
    kenwenzel
    @kenwenzel
    It MUST implement one or more bean interfaces. The Behaviour interface CAN be implemented to access the bean instance itself via getBehaviourDelegate() because 'this' points to the behaviour instance and not to the bean. The generic parameter of Behaviour is just there to avoid type casts.
    lolive
    @lolive
    hello again. if you have some time for me, i still need some clarification about property prefetching in my CONSTRUCT query
    26 replies
    naturzukunft
    @naturzukunft:matrix.org
    [m]

    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!

    kenwenzel
    @kenwenzel

    @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.

    naturzukunft
    @naturzukunft:matrix.org
    [m]
    UseCase:
    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.
    I will try to make my code with unit test available soon. I may also have made a mistake when initialising the entity manager.
    naturzukunft
    @naturzukunft:matrix.org
    [m]

    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.

    kenwenzel
    @kenwenzel
    OK. Do you already use transactions? You should wrap the creation of your entities within a transaction by using
    ITransaction tx = entityManager.getTransaction();
    tx.begin();
    try {
      // create beans here
      tx.commit();
    } catch (KommaException e) {
      // rollback tx if necessary
    }
    BTW, 10s for each setter is way too long. Which KOMMA version are you using? Do you use the IModelSet-API or only the entity manager?
    naturzukunft
    @naturzukunft:matrix.org
    [m]
    Transaction is a good idea, test runtime before 55.853sec with transaction 12.379
    I use 1.4.0, copied it from an example.
    switching to 1.5.2 end in applicationContext errors while initialization.
    is there somewhere an example with 1.5.2 ?
    kenwenzel
    @kenwenzel
    I try to upgrade https://github.com/komma/komma-examples to 1.5.2 tomorrow. But we're already using it in our linked data platform enilink https://github.com/enilink/enilink without any problems... hm...
    @naturzukunft:matrix.org Can you provide your examples/unit tests somehow?
    kenwenzel
    @kenwenzel

    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