polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Querying?
Date Mon, 28 Sep 2015 01:01:53 GMT
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...

On Sep 28, 2015 03:40, "Kent Sølvsten" <kent.soelvsten@gmail.com> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message