Michael Hunger wrote: > SparqlRdfQueryParser: > --------------------- > I introduced 2 of the collection types (Namespaces and Triples) for easier > handling of this stuff so there is a better > separation of concerns. > Regarding the Sparql query rendering. I now moved all the rendering stuff > into the main method (getQuery) so that is > consistently there. Its also possible to add a toSparql-method to > Triples,Triple,Namespaces to let them be responsible > for their own formatting. What do you think about this kind of responsibility > stuff? Where to put such concerns? In a > single class accessing the state of multiple objects and doing the stuff or > rather having the objects doing it for > themselves and just collecting the results?
I have no strong opinions on this one for now. The current code seems ok. > I replaced most of the StringBuilder calls (which were actually just a single > StringBuilder call and not collecting > parameters or such) with String.format which is much more concise and > readable. > I also redid the large "(if then else)+" construct in processFilter with > return-early. Excellent! > There seems to be a GenericAssociationInfo missing? (sister class to > GenericPropertyInfo) ? You mean org.qi4j.entity.association.GenericAssociationInfo? It's there. > RdfEntityFinderMixin: > --------------------- > I added the promised IoC callbacks reducing the size of the class by 2/3. > > Namely: > import > org.qi4j.entity.index.rdf.callback.CollectingQualifiedIdentityResultCallback; > import > org.qi4j.entity.index.rdf.callback.SingleQualifiedIdentityResultCallback; > > the interfaces are: > import org.qi4j.entity.index.rdf.callback.TupleQueryResultCallback; > > import org.qi4j.entity.index.rdf.callback.QualifiedIdentityResultCallback > > all except the > TupleQueryResultCallback,QualifiedIdentityTupleQueryResultCallback belonging > rather to the general entity > finder package. > > First I also had a Counting*Callback but resorted to having performQuery > return the number of rows processed. > > There is/was also an inconsistency. For findEntities/findEntity > null-Identities are ignored and for counting the results > they are included! Do you know why this is? Null's should definitely be ignored in all cases. > At last I replaced inheritance with delegation within the callbacks and now > the tuplequery stuff could be re-inlined > into the RdfEntityFinderMixin (as a separate method processRow(QICallback, > row, QualifiedIdentity). Shall I do this?? Yeah, as it is there doesn't seem to be much point in having it be separate. > SPARQLEntityFinderMixin: > ------------------------ > I also redid the SPARQLEntityFinderMixin with the new IoC callbacks, so > implementing the two missing methods > (findEntity/countEntities). It was just a breeze. Goodie! > RdfEntityFinderTest: > -------------------- > I also added assertions to RdfEntityFinderTest, storing the identity-name > pairs when populating the network and using > this information on the identities returned by the 22 finder tests to assert > that the correct entities were found. > The only test I didn't have the strength adding assertions to was the "dump > the world as rdf" test. Goodie again! > I'd really like to make this test the base for all EntityFinders, much like > the AbstractEntityStoreTest for all > EntityStores. WDYT ? > Pulling the test methods up and just having the assembly setup and the > concrete entity finder in the test subclasses > would be easy. Sounds like a good idea. Ideally all SPI interfaces should have abstract tests to make it easier to create new implementations, and EntityFinder is definitely one of the more central ones. > Now its 5 am and I'm going to get 2 hours of sleep before leaving for work :) Well, great work! Thanks for these excellent fixes! /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
