[jira] [Closed] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andi Huber closed ISIS-1976.
Resolution: Fixed
We have made some progress on this issue, but it does not feel that the task is
finished yet.
However, I'm closing this issue. Work on IoC Container integration will provide
some improvements here anyway.
> 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()).
> Most, though not all, objects have Oids. Certainly DN persistent objects do,
> in fact they do even if they are not yet persisted (prior to calling
> RepositoryService#persist(...). These will have a RootOid, which will
> indicate if the object is persistent or still transient.
> The same is true of view models, these also have a RootOid. They also have a
> RecreatableObjectFacet which is used to actually manufacture the Oid (because
> the oid for view models is basically a serialization of the state of the
> domain object). The RootOid for view models will indicate that they are view
> models.
> Values (ints, strings etc), do NOT have an oid. This also means that -
> obviously - they don't get saved in the OidAdapterHashMap; and they probably
> aren't saved in PojoAdapterHashMap. Value objects will have a ValueFacet.
> There's one other subtype of Oid (apart from RootOid), namely
> ParentedCollectionOid. That's because the Set or List that holds "child"
> objects is also managed as an adapter; ie:
> {code:java}
> public class Order {
>@Getter @Setter
>Set orderItems = Sets.newTreeSet();
>...
> }{code}
> Why is this done? Because a long time ago (before DN) the framework did its
> own persistence, so this was for lazy loading etc.
>
> 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:
> * for DN entities, there is the JdoObjectIdSerlaizer
> * for view models, there's RecreatableObjectFacet, already mentioned.
> [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]
>
> Ideally the code to recreate/rehydrate the object should define a consistent
> API to
[jira] [Closed] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andi Huber closed ISIS-1976.
Resolution: Fixed
The content negotiation parameter 'suppress' does now allow more control on
which '$$..' properties one wants to suppress. New options are
{code:java}
public static enum SuppressionType {
/** suppress '$$RO', RO Spec representation*/
RO,
/** suppress '$$href', hyperlink to the representation*/
HREF,
/** suppress '$$instanceId', instance id of the domain object*/
ID,
/** suppress '$$title', title of the domain object*/
TITLE,
/** suppress all '$$...' entries*/
ALL
}{code}
where these are case-insensitive and may be combined to a comma-separated set.
Eg. to suppress $$title and $$href one could simply request
{noformat}
application/json;profile=urn:org.apache.isis/v1;suppress=title,href
{noformat}
We do not break the previous behavior with 'suppress=true' being equivalent to
'suppress=ro'
> 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()).
> Most, though not all, objects have Oids. Certainly DN persistent objects do,
> in fact they do even if they are not yet persisted (prior to calling
> RepositoryService#persist(...). These will have a RootOid, which will
> indicate if the object is persistent or still transient.
> The same is true of view models, these also have a RootOid. They also have a
> RecreatableObjectFacet which is used to actually manufacture the Oid (because
> the oid for view models is basically a serialization of the state of the
> domain object). The RootOid for view models will indicate that they are view
> models.
> Values (ints, strings etc), do NOT have an oid. This also means that -
> obviously - they don't get saved in the OidAdapterHashMap; and they probably
> aren't saved in PojoAdapterHashMap. Value objects will have a ValueFacet.
> There's one other subtype of Oid (apart from RootOid), namely
> ParentedCollectionOid. That's because the Set or List that holds "child"
> objects is also managed as an adapter; ie:
> {code:java}
> public class Order {
>@Getter @Setter
>Set orderItems = Sets.newTreeSet();
>...
> }{code}
> Why is this done? Because a long time ago (before DN) the framework did its
> own persistence, so this was for lazy loading etc.
>
> 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
>
