[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Haywood updated ISIS-1976:
------------------------------
Description:
The cache management we have with ObjectAdapter, might be simplified such that
we just work with java.lang.Object so far as possible. We would have a
"disposable" ObjectAdapter that we instantiate around an Object whenever we
need it - to access into the metamodel - and then throw it away after. Or
perhaps eventually we might not need ObjectAdapter at all, just simply use
#getClass() to look up the ObjectSpecification.
~~~
The main objective is to get rid of these two maps:
[https://github.com/apache/isis/blob/master/core/runtime/src/main/java/org/apache/isis/core/runtime/system/persistence/adaptermanager/OidAdapterHashMap.java]
and
[https://github.com/apache/isis/blob/master/core/runtime/src/main/java/org/apache/isis/core/runtime/system/persistence/adaptermanager/PojoAdapterHashMap.java]
As their name suggests, these map:
oid -> adapter (look up an adapter from an oid)
pojo -> adapter (look up an adapter from a pojo)
The adapter itself has a reference to its oid (getOid()) and to its pojo
(getObject()).
The "ensureMapsConsistent" method in PersistenceSessionXxx is there to ensure
that these are maintained correctly; it's rather paranoid because if these get
out of sync, then bad things would happen; eg:
[https://github.com/apache/isis/blob/master/core/plugins/jdo-datanucleus-4/src/main/java/org/apache/isis/core/runtime/system/persistence/PersistenceSession4.java#L1184]
There's also some rather horrible "remapRecreatedPojo" methods that hack this
stuff
[https://github.com/apache/isis/blob/master/core/plugins/jdo-datanucleus-4/src/main/java/org/apache/isis/core/runtime/system/persistence/PersistenceSession4.java#L1739]
All this stuff is a legacy from the original client/server architecture that
the framework used to have; it was probably needed then but I really don't
think it's needed now.
~~~
At the moment the object adapters are created eagerly, typically using
PersistenceSession#adapterFor(...). For domain services, we eagerly create an
adapter around every service before each session, "just in case" it gets
interacted with. This could be removed
[https://github.com/apache/isis/blob/master/core/plugins/jdo-datanucleus-4/src/main/java/org/apache/isis/core/runtime/system/persistence/PersistenceSession4.java#L237]
This also requires the ability to infer the Oid from the pojo, on the fly.
There are two different ways this is done:
[https://github.com/apache/isis/blob/master/core/plugins/jdo-datanucleus-4/src/main/java/org/apache/isis/objectstore/jdo/datanucleus/persistence/spi/JdoObjectIdSerializer.java]
To do this for an domain entity (JdoIdHelper) vs for view models
(RecreateableObjectFacet). Ideally the code to recreate/rehydrate the object
should be more transparent
could perhaps provide a pluggable service so that can then support other
persistence runtime stores ... the idea is that the framework encounters a pojo
and then asks for a service (via an SPI) to see which can extract/infer an Oid
from it, using the usual chain-of-responsibility pattern. Out-of-the-box the
framework would provide two default implementations, one for DN entities
(JdoIdHelper), the other for view models.
Ideally, PersistenceSession shouldn't need to use ObjectAdapter at all; the
ObjectAdapter really exists only for the viewer(s) etc to obtain the
ObjectSpecification to know how to render the object. Ultimately, we could get
rid of ObjectAdapter completely and just uses pojos (=domain objects)
everywhere. ObjectSpecification would remain, though. I think this is for
other tickets, though, not this one.
was:The cache management we have with ObjectAdapter, might be simplified such
that we just work with java.lang.Object so far as possible. We would have a
"disposable" ObjectAdapter that we instantiate around an Object whenever we
need it - to access into the metamodel - and then throw it away after. Or
perhaps eventually we might not need ObjectAdapter at all, just simply use
#getClass() to look up the ObjectSpecification.
> Improve the metamodel cache management
> --------------------------------------
>
> Key: ISIS-1976
> URL: https://issues.apache.org/jira/browse/ISIS-1976
> Project: Isis
> Issue Type: Improvement
> Components: Core
> Reporter: Andi Huber
> Assignee: Andi Huber
> Priority: Major
> Fix For: 2.0.0-M2
>
>
> The cache management we have with ObjectAdapter, might be simplified such
> that we just work with java.lang.Object so far as possible. We would have a
> "disposable" ObjectAdapter that we instantiate around an Object whenever we
> need it - to access into the metamodel - and then throw it away after. Or
> perhaps eventually we might not need ObjectAdapter at all, just simply use
> #getClass() to look up the ObjectSpecification.
> ~~~
> The main objective is to get rid of these two maps:
> [https://github.com/apache/isis/blob/master/core/runtime/src/main/java/org/apache/isis/core/runtime/system/persistence/adaptermanager/OidAdapterHashMap.java]
> and
> [https://github.com/apache/isis/blob/master/core/runtime/src/main/java/org/apache/isis/core/runtime/system/persistence/adaptermanager/PojoAdapterHashMap.java]
> As their name suggests, these map:
> oid -> adapter (look up an adapter from an oid)
> pojo -> adapter (look up an adapter from a pojo)
> The adapter itself has a reference to its oid (getOid()) and to its pojo
> (getObject()).
>
> The "ensureMapsConsistent" method in PersistenceSessionXxx is there to ensure
> that these are maintained correctly; it's rather paranoid because if these
> get out of sync, then bad things would happen; eg:
> [https://github.com/apache/isis/blob/master/core/plugins/jdo-datanucleus-4/src/main/java/org/apache/isis/core/runtime/system/persistence/PersistenceSession4.java#L1184]
>
> There's also some rather horrible "remapRecreatedPojo" methods that hack this
> stuff
> [https://github.com/apache/isis/blob/master/core/plugins/jdo-datanucleus-4/src/main/java/org/apache/isis/core/runtime/system/persistence/PersistenceSession4.java#L1739]
>
> All this stuff is a legacy from the original client/server architecture that
> the framework used to have; it was probably needed then but I really don't
> think it's needed now.
> ~~~
> At the moment the object adapters are created eagerly, typically using
> PersistenceSession#adapterFor(...). For domain services, we eagerly create
> an adapter around every service before each session, "just in case" it gets
> interacted with. This could be removed
> [https://github.com/apache/isis/blob/master/core/plugins/jdo-datanucleus-4/src/main/java/org/apache/isis/core/runtime/system/persistence/PersistenceSession4.java#L237]
>
>
> This also requires the ability to infer the Oid from the pojo, on the fly.
> There are two different ways this is done:
> [https://github.com/apache/isis/blob/master/core/plugins/jdo-datanucleus-4/src/main/java/org/apache/isis/objectstore/jdo/datanucleus/persistence/spi/JdoObjectIdSerializer.java]
>
> To do this for an domain entity (JdoIdHelper) vs for view models
> (RecreateableObjectFacet). Ideally the code to recreate/rehydrate the object
> should be more transparent
> could perhaps provide a pluggable service so that can then support other
> persistence runtime stores ... the idea is that the framework encounters a
> pojo and then asks for a service (via an SPI) to see which can extract/infer
> an Oid from it, using the usual chain-of-responsibility pattern.
> Out-of-the-box the framework would provide two default implementations, one
> for DN entities (JdoIdHelper), the other for view models.
>
>
> Ideally, PersistenceSession shouldn't need to use ObjectAdapter at all; the
> ObjectAdapter really exists only for the viewer(s) etc to obtain the
> ObjectSpecification to know how to render the object. Ultimately, we could
> get rid of ObjectAdapter completely and just uses pojos (=domain objects)
> everywhere. ObjectSpecification would remain, though. I think this is for
> other tickets, though, not this one.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
