Yes. The test cases was primarily created by Alin Dreghiciu at a time when the Visibility was messed up, basically when the UnitOfWork creator's visibility became the Visibility of everything storage/indexing/query. That led to a lot of strangeness, and one had to either use a single layer or declare most Visibility.application.
I think what is missing in our Ubiquitous Language ;-) is the separation of "Visibility of API user" and "Visibility of SPI user", but that could be an incorrect generalization. Once I have a home (next weekend) and a Functioning computer, I will try to sort out this concept's requirements, and start look at solutions... Cheers On Sep 28, 2015 03:40, "Kent Sølvsten" <[email protected]> wrote: > Den 27-09-2015 kl. 12:16 skrev Paul Merlin: > > Niclas Hedhman a écrit : > >> You are bringing up a lot of details, and I simply don't have time to > >> investigate the details right now. I will try to remember to revisit > this > >> at a later date. > >> > >> One thing is known; The RDF implementation does the right thing, the SQL > >> implementation doesn't. > >> > >> Why is that? I am not sure. But the intent is that the Query > implementation > >> needs to take the "view position" of the caller, not its own location in > >> the Structure. I think this is what SQL impl is failing, and had to > >> introduce the hack of a type finder (can't recall the exact name). > >> > >> It could be that it is this reason, why the Query impl looks complex, > and I > >> am not able to comment on whether this can be simplified or not. I just > >> hope we won't do the same mistake as 2nd generation of our > >> Persistence/Indexing/Query system, where everything ended up "wrong" in > >> terms of visibility. > > That's the ElasticSearch index/query that does the wrong thing regarding > > visibility, not the SQL one. The SQL one is complex because of, well, > SQL. > I guess that we could really use some more multi-module testcases > hitting those indexers. > > /Kent >
