polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: ValueDeserialization "flaw" ?
Date Fri, 26 Jun 2015 08:45:03 GMT
Let me try to figure out what is required and see how the solution looks
like before making any decision on this.

On Fri, Jun 26, 2015 at 10:44 AM, Niclas Hedhman <niclas@hedhman.org> wrote:

> But ValueSerialization is also "SPI" and you claimed elsewhere that we
> reserve the right to change that...
>
> On Fri, Jun 26, 2015 at 10:07 AM, Paul Merlin <paul@nosphere.org> wrote:
>
>> Niclas,
>>
>> Niclas Hedhman a ├ęcrit :
>> > Gang,
>> >
>> > There is something awkward about the Value Deserialization system, but I
>> > have a hard time to put my finger on it.
>> >
>> > The entity types are found by Entity Store implementations that are
>> > residing in layers below. But value types can't be deserialized without
>> a
>> > valuesModuleFinder (which erroneously assumes a single module for all
>> > types, but that is separate issue) handing a module from layers above.
>> That
>> > shouldn't really be necessary.
>> >
>> > I think that the issue stems from the fact that the UnitOfWork isn't
>> > involved, and there is nothing else carrying this vital information. I
>> also
>> > think that the underlying mistake was to first do "@Structure Module
>> > module" injection into the ValueDeserializerAdapter, later realizing
>> that
>> > wouldn't work (and adding the valuesModuleFinder as a result), but at
>> that
>> > point failing to add Module in the methods instead of the constructor
>> > argument.
>> I think you got the history right :)
>> Seems legit that UoW is not involved as Serialization must work without
>> one, we're talking about Values here.
>>
>> > I will see if I can come up with a solution to this.
>> >
>> > Any feedback is appreciated, as always...
>> Unfortunately, adding Module in the methods would break API
>> compatibility. If it's the way to go, we could add new methods with a
>> Module parameter and @Deprecate the other methods planning their removal
>> for 3.0.
>>
>> HTH
>>
>> /Paul
>>
>>
>
>
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

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