Hi,

Niclas Hedhman wrote:
Update on Named Query support;

The NamedEntityFinder service is getting (during bootstrap) a
meta-info class called NamedQueries, which is essentially a map of
named queries, string to NamedQueryDescriptor.

Like Edward said, this needs to be related to the domain, rather than the service, isn't it? How to do that I'm not really sure though..

To use it, it would look like;

   UnitOfWork uow = uowf.currentUnitOfWork();
   Query<Predator> query = qbf.newNamedQuery( Predator.class, uow,
"findPredatorsOfFlyingAnimals" );
   for( Predator predator : query )
   {
     ...
   }

This looks ok to me.

Now, it is for the Sparql language easy to support the firstResult()
and maxResults() in the Query. It is just appended at the end of the
sparql query.

But for OrderBy, the story is much more complicated, and I have
currently not reached a satisfactory solution. The problem is somewhat
two fold;

1. The Query Runtime is pretty tightly tied into the Property model
for picking the sort keys. I don't want to modify the Query (and half
a dozen internal classes) to support "orderBy( String name )". The
good news is that the templateFor() to obtain sorting properties are
QueryBuilder agnostic, so that works.

2. But, since the query is handwritten, it is really(!) hard to figure
out which Sparql 'variable' that a particular property refers to.


So, I don't know what I should do...

I have begun to realize that a major flaw in the general thinking about the Query API is that, along the thinking of the CommandQuery separation discussion on the DDD list, there is not generally a relation between the domain model and queries. If there is, that's a coincidence more than anything else. The reason is that the queries support the clients view and the operations to be performed, which is not necessarily related to how the domain model is structured. I have this case myself now, where the queries to support the client are sort of different from how the domain model is constructed. The client has "views" of the domain model, rather than the domain model. In this case there is meaning to "use the domain model" to construct the query where-expression.

I have so far added very limited support. The query string in the
NamedSparqlDescriptor contains the "ORDER BY" clause, and the
Query.orderBy() is required to have the same properties for in the
same order, and only the ASC or DESC is modified in the query string.

In the testcase I have this;

   Person person = templateFor( Person.class );
   final Query<Person> query = qbf.newNamedQuery( Person.class,
unitOfWork, "script21" );
   query.orderBy( orderBy( person.placeOfBirth().get().name() ),
                       orderBy( person.yearOfBirth() ) );

where the "script21" is the following query;

    "PREFIX ns1: <urn:qi4j:type:org.qi4j.index.rdf.model.Person#> \n" +
    "PREFIX ns2: <urn:qi4j:type:org.qi4j.index.rdf.model.Nameable#> \n" +
    "PREFIX ns0: <urn:qi4j:type:org.qi4j.api.entity.Identity#> \n" +
    "PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> \n" +
    "PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> \n" +
    "SELECT DISTINCT ?entityType ?identity\n" +
    "WHERE {\n" +
    "?entityType rdfs:subClassOf
<urn:qi4j:type:org.qi4j.index.rdf.model.Person>. \n" +
    "?entity rdf:type ?entityType. \n" +
    "?entity ns0:identity ?identity. \n" +
    "?entity ns1:placeOfBirth ?v0. \n" +
    "?v0 ns2:name ?v1. \n" +
    "?entity ns1:yearOfBirth ?v2. \n" +
    "\n" +
    "}  ORDER BY DESC(?v1) DESC(?v2)", //script21

So since the code says that the order should be Ascending (the
default), the DESC() declarations are changed to ASC() when the query
is executed. BUT if the query.orderBy() sends in a directives of
either other properties, or those in a different order, the wrong
result will occur.

This seems acceptable to me.

The only other choice I can think of, is to not support orderBy
changes in the Query at all.


Feedback requested.

Good questions, and I don't have too many answers right now, other than that I think we missed something when thinking of the Query API as being closely related to the domain model in the first place...

/Rickard

_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev

Reply via email to