polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niclas Hedhman (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (POLYGENE-132) Improve Indexing/Query Semantics
Date Mon, 10 Apr 2017 06:06:41 GMT

    [ https://issues.apache.org/jira/browse/POLYGENE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15239459#comment-15239459
] 

Niclas Hedhman edited comment on POLYGENE-132 at 4/10/17 6:06 AM:
------------------------------------------------------------------

The reason that the EntityStore can see the types sits in with the fact that the UnitOfWork
has two parts, UnitOfWorkInstance and ModuleUnitOfWork respectively, where the first is created
when newUnitOfWork() is executed, but the ModuleUnitOfWork is injected where it is used (and
in turn referencing the UnitOfWorkInstance). This design came about as the first version had
missed the whole visibility design completely, effectively requiring everything to be visible
(from the top where the UoW was created). 

This mechanism is deeply integrated into the UnitOfWork flow, and there is a huge chunk of
code in ModuleUnitOfWork that implements a QuerySource, which I suspect is the key to get
the faulty query engines to work again, without ValueFinder concept.


On a larger note, IF we intend to make the UnitOfWork a pluggable Composite type, then we
probably need to figure out what the generic mechanism that is at play here.  It is some type
of Module Injected Interceptor, or....?? Probably need a whiteboard and a fellow Polygenetic
person to discuss it in depth.


was (Author: niclas):
The reason that the EntityStore can see the types sits in with the fact that the UnitOfWork
has two parts, UnitOfWorkInstance and ModuleUnitOfWork respectively, where the first is created
when newUnitOfWork() is executed, but the ModuleUnitOfWork is injected where it is used (and
in turn referencing the UnitOfWorkInstance). This design came about as the first version had
missed the whole visibility design completely, effectively requiring everything to be visible
(from the top where the UoW was created). 

This mechanism is deeply integrated into the UnitOfWork flow, and there is a huge chunk of
code in ModuleUnitOfWork that implements a QuerySource, which I suspect is the key to get
the faulty query engines to work again, without ValueFinder concept.


On a larger note, IF we intend to make the UnitOfWork a pluggable Composite type, then we
probably need to figure out what the generic mechanism that is at play here.  It is some type
of Module Injected Interceptor, or....?? Probably need a whiteboard and a fellow Polygenetic
peson to discuss it in depth.

> Improve Indexing/Query Semantics
> --------------------------------
>
>                 Key: POLYGENE-132
>                 URL: https://issues.apache.org/jira/browse/POLYGENE-132
>             Project: Polygene
>          Issue Type: Bug
>            Reporter: Kent SĂžlvsten
>             Fix For: 3.0
>
>
> The current Indexer/Query semantics are not consistent with the EntityStore semantics
and needs to be fixed.
> I can query for an existing entity, IF i can see it's model, AND
> i can see an indexer, AND the entitystore in which the entity is
> persisted can see the same indexer.
> For the EntityStore case, I can get an existing entity if and only if i can see it's
model (according to visibility rules).
> The latter should be the case for Query as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message