polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Merlin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (POLYGENE-105) ValueSerialization Type Lookup is wrong.
Date Mon, 06 Mar 2017 16:39:32 GMT

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

Paul Merlin commented on POLYGENE-105:
--------------------------------------

Most of this is already fixed. There's no more "Value module finder" concept, the deserialization
api was changed to pass the module to use.

What is missing is changing the deserialization implementations so that they use the looked
up value type's module as a starting point when deserializing nested values. BTW, JSONEntityState
suffers from the same flaw.

I'm having a hard time coming up with a test case that fail with the actual implementation.
[~niclas], I could use a hand here, any chance you could express this in (pseudo) code?
If you want to actually write it in code, it should be doable on the develop branch, I'll
adapt it to my serialization-3 branch.


> ValueSerialization Type Lookup is wrong.
> ----------------------------------------
>
>                 Key: POLYGENE-105
>                 URL: https://issues.apache.org/jira/browse/POLYGENE-105
>             Project: Polygene
>          Issue Type: Sub-task
>    Affects Versions: 2.0, 2.1
>            Reporter: Niclas Hedhman
>             Fix For: 3.0
>
>
> The ValueSerialization extensions are dependent on type lookup when deserializing values,
but they go about it in the wrong way. They make the type lookup relative to their own Module,
which completely breaks everything, and it can't even be worked around in many cases.
> Entities that has values in them, are not prone to this, since a slightly different approach
is done in the entity store, although I am not sure it is immune to this Visibility/TypeLookup
issue.
> There is even a "Values Module Finder" feature in the whole subsystem, which is a hack-ish
work-around the short-comings of the actual API.
> At a minimum, a Module needs to be provided for which the Visibility should be computed
from. It is likely that the Module used is dynamic, and changes as the Value Type tree is
traversed, i.e. when a nested type is "found" its Module (i.e. the module it was found in)
should be used for its further TypeLookup operations. This mimics the UnitOfWork to a much
closer degree. 
> The necessary model elements are present, and to correct the implementations shouldn't
be too hard, but there will be a change in the ValueSerialization API/SPI, and we should simply
delay the change until 3.0. There might be many over wanted changes that could affect the
new design.



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

Mime
View raw message