EntityReference in ValueComposite 'side effect'

[Niclas Hedhman <ni...@hedhman.org>]

Gang,

the new EntityStoreTestSuite is once again finding "interesting" behavior
that is not documented.

If an Value composite has an Association to an Entity, but that entity is
not visible to the Value, deserialization will fail.

It is quite straight forward that it does, since serialization doesn't have
the benefit of, for instance, exposed services that does the creation in
the first place, which is a pattern that I typically follow.

However, that is not the end of it... This happens on creating the Value
composite as well, because during the build of the Value, the Constraints
check will actually load the referenced Entity IF (and only IF) there is an
UnitOfWork. If there is no UnitOfWork active, then that particular check is
skipped and the problem probably surface later (I can't figure that out
exactly).


Sooooo.... I think the documentation needs something like;

"For any Associations in Value composites, the Entity type referenced must
be visible in the module of the Value type."

And, then I thought, *let's check this during Model creation and give a
good exception*.

Well, that would have worked if not TypeLookUp now has a LazyInitialization
which get buggered up if called prior to completed, and everything else
breaks. So, I need to disable that until we can disable lazy-loading in
TypeLookUp during model building.


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

Re: EntityReference in ValueComposite 'side effect'

[Niclas Hedhman <ni...@hedhman.org>]

Perhaps. I think "Activation" might have an influence and could throw a
spanner in the works. SO, I want to get to the bottom of that, before
figuring out what can be cached when.

On Tue, Jul 4, 2017 at 12:47 AM, Paul Merlin <pa...@apache.org> wrote:

> Niclas Hedhman a écrit :
> > Gang,
> >
> > the new EntityStoreTestSuite is once again finding "interesting" behavior
> > that is not documented.
> >
> > If an Value composite has an Association to an Entity, but that entity is
> > not visible to the Value, deserialization will fail.
> >
> > It is quite straight forward that it does, since serialization doesn't
> have
> > the benefit of, for instance, exposed services that does the creation in
> > the first place, which is a pattern that I typically follow.
> >
> > However, that is not the end of it... This happens on creating the Value
> > composite as well, because during the build of the Value, the Constraints
> > check will actually load the referenced Entity IF (and only IF) there is
> an
> > UnitOfWork. If there is no UnitOfWork active, then that particular check
> is
> > skipped and the problem probably surface later (I can't figure that out
> > exactly).
> >
> >
> > Sooooo.... I think the documentation needs something like;
> >
> > "For any Associations in Value composites, the Entity type referenced
> must
> > be visible in the module of the Value type."
> >
> > And, then I thought, *let's check this during Model creation and give a
> > good exception*.
> >
> > Well, that would have worked if not TypeLookUp now has a
> LazyInitialization
> > which get buggered up if called prior to completed, and everything else
> > breaks. So, I need to disable that until we can disable lazy-loading in
> > TypeLookUp during model building.
>
> Hey,
>
> About TypeLookup & caching.
>
> Caching exists to alleviate obvious performance problems during runtime
> and is possible because, once bootstrapped, the application model
> doesn't change.
>
> We could move the caching to some TypeLookup decorator that we would
> only use at runtime, and use the non-caching implementation during
> bootstrap.
>
> That could solve this use case, correct?
>
> Cheers
>
> /Paul
>
>
>
>


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

Re: EntityReference in ValueComposite 'side effect'

[Paul Merlin <pa...@apache.org>]

Niclas Hedhman a écrit :
> Gang,
>
> the new EntityStoreTestSuite is once again finding "interesting" behavior
> that is not documented.
>
> If an Value composite has an Association to an Entity, but that entity is
> not visible to the Value, deserialization will fail.
>
> It is quite straight forward that it does, since serialization doesn't have
> the benefit of, for instance, exposed services that does the creation in
> the first place, which is a pattern that I typically follow.
>
> However, that is not the end of it... This happens on creating the Value
> composite as well, because during the build of the Value, the Constraints
> check will actually load the referenced Entity IF (and only IF) there is an
> UnitOfWork. If there is no UnitOfWork active, then that particular check is
> skipped and the problem probably surface later (I can't figure that out
> exactly).
>
>
> Sooooo.... I think the documentation needs something like;
>
> "For any Associations in Value composites, the Entity type referenced must
> be visible in the module of the Value type."
>
> And, then I thought, *let's check this during Model creation and give a
> good exception*.
>
> Well, that would have worked if not TypeLookUp now has a LazyInitialization
> which get buggered up if called prior to completed, and everything else
> breaks. So, I need to disable that until we can disable lazy-loading in
> TypeLookUp during model building.

Hey,

About TypeLookup & caching.

Caching exists to alleviate obvious performance problems during runtime
and is possible because, once bootstrapped, the application model
doesn't change.

We could move the caching to some TypeLookup decorator that we would
only use at runtime, and use the non-caching implementation during
bootstrap.

That could solve this use case, correct?

Cheers

/Paul