Adam Heath wrote:
Moving the caching higher implies that the constructed delegator won't
be saved until it is completely done being constructed. However,
during construction, the delegator creates several helper entities.
These include EntityCrypto, and the cache support classes. These
classes also still have the same problem of not storing delegator
instances, instead just storing a name. So, they try to load a
delegator with the correct name, and don't find it, because the
original delegator is not done being constructed.
But, we still aren't done with this particular problem.
When GenericPK and GenericValue get created, they try to set their
fields. Setting any field on a GenericEntity requires that it knows
it's delegator. However, creation doesn't actually set the delegator.
Even the delegator name is null. So any GenericEntity created during
delegator instantiation ends up trying to load a delegator named
"default", *not* with whatever delegator is actually being created.
I ran into that circular logic problem in the ExecutionContext branch. I
agree - there are a lot of problems with the delegator implementation
and they should be fixed. Let me know if there is anything I can do to help.
