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:44:01 GMT
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

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