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.