[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16639590#comment-16639590
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 9698a405ea18d71c88ee9641baa3040c76e8c1e5 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=9698a40 ]
ISIS-1976: adds a meta-model (XML) export to the prototyping menu
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/jd
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16639652#comment-16639652
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 9f262ab4f4c0281799a5f7e7091b344aecb2db58 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=9f262ab ]
ISIS-1976: moving responsibility for mixed in action lookup into
ObjectSpecification API
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/apa
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16639653#comment-16639653
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 9f262ab4f4c0281799a5f7e7091b344aecb2db58 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=9f262ab ]
ISIS-1976: moving responsibility for mixed in action lookup into
ObjectSpecification API
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/apa
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16639591#comment-16639591
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 9698a405ea18d71c88ee9641baa3040c76e8c1e5 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=9698a40 ]
ISIS-1976: adds a meta-model (XML) export to the prototyping menu
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/jd
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16639599#comment-16639599
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 90df9d7c2b224f0951706a127689eba6846a6d15 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=90df9d7 ]
ISIS-1976: fixes event-handler annotation processing (MM method-removal)
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/objects
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16639600#comment-16639600
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 90df9d7c2b224f0951706a127689eba6846a6d15 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=90df9d7 ]
ISIS-1976: fixes event-handler annotation processing (MM method-removal)
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/objects
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16639312#comment-16639312
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 728903026415136dff6cd8c6da94805018070120 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=7289030 ]
ISIS-1976: polishing SemanticsOf java-doc
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/persistenc
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16639311#comment-16639311
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 728903026415136dff6cd8c6da94805018070120 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=7289030 ]
ISIS-1976: polishing SemanticsOf java-doc
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/persistenc
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638935#comment-16638935
]
ASF subversion and git services commented on ISIS-1976:
---
Commit b7dd0126dc1c75111837fbd02f88de07c07ca007 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=b7dd012 ]
ISIS-1976: cleanup, also let ServiceInjector's state be consistent when
service list gets modified
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/ja
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638936#comment-16638936
]
ASF subversion and git services commented on ISIS-1976:
---
Commit b7dd0126dc1c75111837fbd02f88de07c07ca007 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=b7dd012 ]
ISIS-1976: cleanup, also let ServiceInjector's state be consistent when
service list gets modified
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/ja
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638882#comment-16638882
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 9d4327e10edc1d6ca82be48b61f6b53fb8eda982 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=9d4327e ]
ISIS-1976: fixing DN tests
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/JdoObject
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638881#comment-16638881
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 9d4327e10edc1d6ca82be48b61f6b53fb8eda982 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=9d4327e ]
ISIS-1976: fixing DN tests
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/JdoObject
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638867#comment-16638867
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 09bee70cbe57dad1703f6adfed0ae0c24935dddb in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=09bee70 ]
ISIS-1976: fixing tests that that fail on mockup service lookup now
being Optionals
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/i
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638868#comment-16638868
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 09bee70cbe57dad1703f6adfed0ae0c24935dddb in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=09bee70 ]
ISIS-1976: fixing tests that that fail on mockup service lookup now
being Optionals
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/i
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638823#comment-16638823
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 5472bf916e80c43c46320725aa0df5faa9d2aa21 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=5472bf9 ]
ISIS-1976: polishing ServiceInjector and ServiceRegistry API
let ServiceInjector implement ServiceRegistry
service lookup result is now an Optional instead of a nullable Object
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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:
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638824#comment-16638824
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 5472bf916e80c43c46320725aa0df5faa9d2aa21 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=5472bf9 ]
ISIS-1976: polishing ServiceInjector and ServiceRegistry API
let ServiceInjector implement ServiceRegistry
service lookup result is now an Optional instead of a nullable Object
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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:
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638572#comment-16638572
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 3d0d716138824e32d5b8ea95ce3f740d88a3a623 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=3d0d716 ]
ISIS-1976: fixes type inference issues, where javac won't compile
while the eclipse java compiler (EJC) has no problem
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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-data
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638571#comment-16638571
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 3d0d716138824e32d5b8ea95ce3f740d88a3a623 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=3d0d716 ]
ISIS-1976: fixes type inference issues, where javac won't compile
while the eclipse java compiler (EJC) has no problem
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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-data
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638498#comment-16638498
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 9d9f1224a4e6fffe85bcacbcc1b57fe7b7d4ab76 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=9d9f122 ]
ISIS-1976: cleaning up some raw types, unchecked casts and incomplete
switches
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/o
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638499#comment-16638499
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 9d9f1224a4e6fffe85bcacbcc1b57fe7b7d4ab76 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=9d9f122 ]
ISIS-1976: cleaning up some raw types, unchecked casts and incomplete
switches
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/o
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638235#comment-16638235
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 1c1ccb9ce823fa69b92a86e91cd1a6c20f5d14b9 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=1c1ccb9 ]
ISIS-1976: fixes NPE on predicate composition
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/persis
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638232#comment-16638232
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 64b71b277b560c7c723b7ed84403bc7daabc91af in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=64b71b2 ]
ISIS-1976: remove runtime dependency on 'log4j'
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/pers
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638234#comment-16638234
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 1c1ccb9ce823fa69b92a86e91cd1a6c20f5d14b9 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=1c1ccb9 ]
ISIS-1976: fixes NPE on predicate composition
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/persis
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638233#comment-16638233
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 64b71b277b560c7c723b7ed84403bc7daabc91af in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=64b71b2 ]
ISIS-1976: remove runtime dependency on 'log4j'
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/pers
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638218#comment-16638218
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 2fa89abb8ee401d8d646323e1463f0bcec950d19 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=2fa89ab ]
ISIS-1976: removing guava from plugins 'shiro' and 'axon'
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/datanu
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638219#comment-16638219
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 2fa89abb8ee401d8d646323e1463f0bcec950d19 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=2fa89ab ]
ISIS-1976: removing guava from plugins 'shiro' and 'axon'
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/datanu
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638213#comment-16638213
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 514aa857d60bcb5d02e5489e1ca5bc9d255ccd41 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=514aa85 ]
ISIS-1976: finally removing guava from runtime module
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/datanucleu
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638211#comment-16638211
]
ASF subversion and git services commented on ISIS-1976:
---
Commit eac84c28380aa19b7e0e8d7a945e5f146dbb6a58 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=eac84c2 ]
ISIS-1976: remove guava from DN-4/5 plugins
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/persiste
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638212#comment-16638212
]
ASF subversion and git services commented on ISIS-1976:
---
Commit eac84c28380aa19b7e0e8d7a945e5f146dbb6a58 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=eac84c2 ]
ISIS-1976: remove guava from DN-4/5 plugins
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/persiste
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638214#comment-16638214
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 514aa857d60bcb5d02e5489e1ca5bc9d255ccd41 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=514aa85 ]
ISIS-1976: finally removing guava from runtime module
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/datanucleu
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638056#comment-16638056
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 51ea2ade8e4a03ea9ab0988477e6c2ea8beddd6f in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=51ea2ad ]
ISIS-1976: remove meta-model dependency on 'javax.inject' and
'javax.validation' since already
provided by JEE API
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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-datanucle
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638057#comment-16638057
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 51ea2ade8e4a03ea9ab0988477e6c2ea8beddd6f in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=51ea2ad ]
ISIS-1976: remove meta-model dependency on 'javax.inject' and
'javax.validation' since already
provided by JEE API
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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-datanucle
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638048#comment-16638048
]
ASF subversion and git services commented on ISIS-1976:
---
Commit ae3bcfc0ff3ce1d189e5ac36ad6480c1aeb26f96 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=ae3bcfc ]
ISIS-1976: remove meta-model dependency on 'gson'
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/pe
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638047#comment-16638047
]
ASF subversion and git services commented on ISIS-1976:
---
Commit ae3bcfc0ff3ce1d189e5ac36ad6480c1aeb26f96 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=ae3bcfc ]
ISIS-1976: remove meta-model dependency on 'gson'
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/pe
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638041#comment-16638041
]
ASF subversion and git services commented on ISIS-1976:
---
Commit fe6eac618865bf541e1ea8125f1258206a830ea1 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=fe6eac6 ]
ISIS-1976: remove meta-model dependency on 'commons-codec'
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/datan
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638040#comment-16638040
]
ASF subversion and git services commented on ISIS-1976:
---
Commit fe6eac618865bf541e1ea8125f1258206a830ea1 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=fe6eac6 ]
ISIS-1976: remove meta-model dependency on 'commons-codec'
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/datan
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638024#comment-16638024
]
ASF subversion and git services commented on ISIS-1976:
---
Commit e03e0294b469d431750cb5dbc99629d6cbd9e45e in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=e03e029 ]
ISIS-1976: finally removing guava from metamodel
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/per
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638023#comment-16638023
]
ASF subversion and git services commented on ISIS-1976:
---
Commit e03e0294b469d431750cb5dbc99629d6cbd9e45e in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=e03e029 ]
ISIS-1976: finally removing guava from metamodel
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/per
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633849#comment-16633849
]
ASF subversion and git services commented on ISIS-1976:
---
Commit dbfc2b56d76d9f32c6c55af9831eea418c190903 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=dbfc2b5 ]
ISIS-1976: Improve the service lookup API (streams instead of
collections)
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/objec
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633851#comment-16633851
]
ASF subversion and git services commented on ISIS-1976:
---
Commit eaeb0fe9178566299697b1aec56486aab7a72860 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=eaeb0fe ]
ISIS-1976: cleanup ServiceUtil
improve ServiceInjector's service list validation for uniqueness to
print all! duplicates
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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-da
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633850#comment-16633850
]
ASF subversion and git services commented on ISIS-1976:
---
Commit eaeb0fe9178566299697b1aec56486aab7a72860 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=eaeb0fe ]
ISIS-1976: cleanup ServiceUtil
improve ServiceInjector's service list validation for uniqueness to
print all! duplicates
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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-da
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633848#comment-16633848
]
ASF subversion and git services commented on ISIS-1976:
---
Commit dbfc2b56d76d9f32c6c55af9831eea418c190903 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=dbfc2b5 ]
ISIS-1976: Improve the service lookup API (streams instead of
collections)
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/objec
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633230#comment-16633230
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 4d98c3d7e0fcb748e38d19d6e0ce2caee96369e9 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=4d98c3d ]
ISIS-1976: remove MutableProposedHolder
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633220#comment-16633220
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 9072e5208cf1b4f0a832553dce8afc02ee664391 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=9072e52 ]
ISIS-1976: remove InstanceAbstract
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/J
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633229#comment-16633229
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 08471fe94051d324697fc0cb1244a571f794300f in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=08471fe ]
ISIS-1976: remove ObjectAdapter.Functions, also rename some OA Utilities
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/objects
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633221#comment-16633221
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 9072e5208cf1b4f0a832553dce8afc02ee664391 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=9072e52 ]
ISIS-1976: remove InstanceAbstract
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/J
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633227#comment-16633227
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 53cb555c802f3bb09a04354ffae08d5e60b3478d in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=53cb555 ]
ISIS-1976: move ObjectAdapter.getIconName() up the hierarchy
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/dat
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633228#comment-16633228
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 08471fe94051d324697fc0cb1244a571f794300f in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=08471fe ]
ISIS-1976: remove ObjectAdapter.Functions, also rename some OA Utilities
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/objects
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633226#comment-16633226
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 53cb555c802f3bb09a04354ffae08d5e60b3478d in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=53cb555 ]
ISIS-1976: move ObjectAdapter.getIconName() up the hierarchy
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/dat
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633231#comment-16633231
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 4d98c3d7e0fcb748e38d19d6e0ce2caee96369e9 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=4d98c3d ]
ISIS-1976: remove MutableProposedHolder
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633223#comment-16633223
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 2d1a08ea2fd1144978dcec674b80221340fa2875 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=2d1a08e ]
ISIS-1976: remove Instance
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/JdoObject
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633222#comment-16633222
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 2d1a08ea2fd1144978dcec674b80221340fa2875 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=2d1a08e ]
ISIS-1976: remove Instance
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/JdoObject
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633224#comment-16633224
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 0b7afc6eb8cc0c7d48691eed9697be9f0d930963 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=0b7afc6 ]
ISIS-1976: rename ObjectAdapter.getObject() -> getPojo()
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/datanuc
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633225#comment-16633225
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 0b7afc6eb8cc0c7d48691eed9697be9f0d930963 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=0b7afc6 ]
ISIS-1976: rename ObjectAdapter.getObject() -> getPojo()
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/datanuc
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633086#comment-16633086
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 8cffeff7f819ed2e9b025a6eecd3ca387205f2e1 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=8cffeff ]
ISIS-1976: cleaning up, removing lines that were commented out
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/d
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633087#comment-16633087
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 8cffeff7f819ed2e9b025a6eecd3ca387205f2e1 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=8cffeff ]
ISIS-1976: cleaning up, removing lines that were commented out
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/d
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633084#comment-16633084
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 9b0826c4ccddd7cad5138e1ee4fe57fde181af04 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=9b0826c ]
ISIS-1976: add deprecation marker
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/Jd
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633083#comment-16633083
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 9b0826c4ccddd7cad5138e1ee4fe57fde181af04 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=9b0826c ]
ISIS-1976: add deprecation marker
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/Jd
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633079#comment-16633079
]
ASF subversion and git services commented on ISIS-1976:
---
Commit cc497036ed0df60f5e03498e1d817d01a8af3489 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=cc49703 ]
ISIS-1976: cleaning up FIXME markers
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633078#comment-16633078
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 021d8e80b49eaf0b9451caebf7ae5d71e32306af in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=021d8e8 ]
ISIS-1976: generate element specification on the fly
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633077#comment-16633077
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 021d8e80b49eaf0b9451caebf7ae5d71e32306af in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=021d8e8 ]
ISIS-1976: generate element specification on the fly
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633076#comment-16633076
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 5985538b886152b4bc2081b08fc67e80fe371de6 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=5985538 ]
ISIS-1976: move element spec. property from OA into ObjectSpecification
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/objectst
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633080#comment-16633080
]
ASF subversion and git services commented on ISIS-1976:
---
Commit cc497036ed0df60f5e03498e1d817d01a8af3489 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=cc49703 ]
ISIS-1976: cleaning up FIXME markers
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633075#comment-16633075
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 5985538b886152b4bc2081b08fc67e80fe371de6 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=5985538 ]
ISIS-1976: move element spec. property from OA into ObjectSpecification
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/objectst
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16632780#comment-16632780
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 63b18b8eb552612e1ee4586ec1ac9d9f5655c02e in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=63b18b8 ]
ISIS-1976: CollectionFacet API: make collection pojo creation a
responsibility of the facet
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16632782#comment-16632782
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 3a1bd77ce47dea41dc4dd3da2aee6b4f14d9850b in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=3a1bd77 ]
ISIS-1976: CollectionFacet API: remove contains(..)
improves memento one-to-many update performance
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16632779#comment-16632779
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 63b18b8eb552612e1ee4586ec1ac9d9f5655c02e in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=63b18b8 ]
ISIS-1976: CollectionFacet API: make collection pojo creation a
responsibility of the facet
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16632781#comment-16632781
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 3a1bd77ce47dea41dc4dd3da2aee6b4f14d9850b in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=3a1bd77 ]
ISIS-1976: CollectionFacet API: remove contains(..)
improves memento one-to-many update performance
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16632515#comment-16632515
]
ASF subversion and git services commented on ISIS-1976:
---
Commit f6c1f181af447d0ec51bad21366033c10df6fae1 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=f6c1f18 ]
ISIS-1976: minor: move static ElementSpecificationProvider factory from
facet to the interface itself
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16632514#comment-16632514
]
ASF subversion and git services commented on ISIS-1976:
---
Commit f6c1f181af447d0ec51bad21366033c10df6fae1 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=f6c1f18 ]
ISIS-1976: minor: move static ElementSpecificationProvider factory from
facet to the interface itself
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16632518#comment-16632518
]
ASF subversion and git services commented on ISIS-1976:
---
Commit f9ebfa2adc414d69d602d76d59fdf875f192dd26 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=f9ebfa2 ]
ISIS-1976: facet lookup: cleanup some code smell
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/per
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16632516#comment-16632516
]
ASF subversion and git services commented on ISIS-1976:
---
Commit f9ebfa2adc414d69d602d76d59fdf875f192dd26 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=f9ebfa2 ]
ISIS-1976: facet lookup: cleanup some code smell
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/per
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16632220#comment-16632220
]
ASF subversion and git services commented on ISIS-1976:
---
Commit a445986c9bb3c8881c1960ef7edef6c348986e26 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=a445986 ]
ISIS-1976: rework CollectionFacet API such that methods invoked on
non-scalar types preserves their generic type nature
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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-data
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16632219#comment-16632219
]
ASF subversion and git services commented on ISIS-1976:
---
Commit a445986c9bb3c8881c1960ef7edef6c348986e26 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=a445986 ]
ISIS-1976: rework CollectionFacet API such that methods invoked on
non-scalar types preserves their generic type nature
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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-data
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16631889#comment-16631889
]
ASF subversion and git services commented on ISIS-1976:
---
Commit f9ce63f44640eb399949ca89d8ac79a1f29beedb in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=f9ce63f ]
ISIS-1976: replace PropertyOrCollectionAccessorFacet.getProperty(OA, ..)
-> getProperty(Instance, ..)
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16631891#comment-16631891
]
ASF subversion and git services commented on ISIS-1976:
---
Commit daaf777dc802963d4cc98ba71d16a507673cfa07 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=daaf777 ]
ISIS-1976: introduces ManagedObject to replace OA within
most of metamodel
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/objec
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16631894#comment-16631894
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 58c450f5b0841d81d7816a24eaa3fbd1ca67dfd1 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=58c450f ]
ISIS-1976: remove leftovers from bulk action support
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16631890#comment-16631890
]
ASF subversion and git services commented on ISIS-1976:
---
Commit daaf777dc802963d4cc98ba71d16a507673cfa07 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=daaf777 ]
ISIS-1976: introduces ManagedObject to replace OA within
most of metamodel
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/objec
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16631888#comment-16631888
]
ASF subversion and git services commented on ISIS-1976:
---
Commit f9ce63f44640eb399949ca89d8ac79a1f29beedb in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=f9ce63f ]
ISIS-1976: replace PropertyOrCollectionAccessorFacet.getProperty(OA, ..)
-> getProperty(Instance, ..)
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16631893#comment-16631893
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 58c450f5b0841d81d7816a24eaa3fbd1ca67dfd1 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=58c450f ]
ISIS-1976: remove leftovers from bulk action support
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16631881#comment-16631881
]
ASF subversion and git services commented on ISIS-1976:
---
Commit f8358ab793a0813c9c62fd521541e48e6a0b6c3e in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=f8358ab ]
ISIS-1976: 'pulling up': ContributeeMember2 and MixedInMemeber2
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16631884#comment-16631884
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 8d6abe65deb29d313f9b722503a784e173f46fba in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=8d6abe6 ]
ISIS-1976: minor: renaming and cleanup
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/s
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16631885#comment-16631885
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 8d6abe65deb29d313f9b722503a784e173f46fba in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=8d6abe6 ]
ISIS-1976: minor: renaming and cleanup
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/s
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16631886#comment-16631886
]
ASF subversion and git services commented on ISIS-1976:
---
Commit c18fb53ae08d68cd8399d96f26d92590455e5804 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=c18fb53 ]
ISIS-1976: minor: simplify OA for viewmodel creation when via
mamentoString
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/obje
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16631883#comment-16631883
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 168354de94e485bdcecdf97b57a2fbf950f0fda7 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=168354d ]
ISIS-1976: cleanup CollectionData API
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/sp
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16631880#comment-16631880
]
ASF subversion and git services commented on ISIS-1976:
---
Commit f8358ab793a0813c9c62fd521541e48e6a0b6c3e in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=f8358ab ]
ISIS-1976: 'pulling up': ContributeeMember2 and MixedInMemeber2
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16631887#comment-16631887
]
ASF subversion and git services commented on ISIS-1976:
---
Commit c18fb53ae08d68cd8399d96f26d92590455e5804 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=c18fb53 ]
ISIS-1976: minor: simplify OA for viewmodel creation when via
mamentoString
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/obje
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16631882#comment-16631882
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 168354de94e485bdcecdf97b57a2fbf950f0fda7 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=168354d ]
ISIS-1976: cleanup CollectionData API
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/sp
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16629437#comment-16629437
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 8f3ead39d1eb6504aafa5595600ee8974849f2e6 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=8f3ead3 ]
ISIS-1976: fixes 'Command' having field 'uniqueId' not initialized
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/j
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16629436#comment-16629436
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 8f3ead39d1eb6504aafa5595600ee8974849f2e6 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=8f3ead3 ]
ISIS-1976: fixes 'Command' having field 'uniqueId' not initialized
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/j
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16629389#comment-16629389
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 30eb4dfc198bbc1232e0c16895c3c92c42f32d3c in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=30eb4df ]
ISIS-1976: further cleanup
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/JdoObject
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16629390#comment-16629390
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 30eb4dfc198bbc1232e0c16895c3c92c42f32d3c in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=30eb4df ]
ISIS-1976: further cleanup
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/JdoObject
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16629329#comment-16629329
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 4e7ea3142403412fd495856d68fe291bc368c687 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=4e7ea31 ]
ISIS-1976: cleanup after removal of bulk action support
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/datanucl
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16629330#comment-16629330
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 4e7ea3142403412fd495856d68fe291bc368c687 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=4e7ea31 ]
ISIS-1976: cleanup after removal of bulk action support
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/datanucl
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16629318#comment-16629318
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 9283f47adf2491e70da1c042f31011038f1ad591 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=9283f47 ]
ISIS-1976: remove deprecated MetaModelServce.sortOf methods not having
the Mode argument
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/apa
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16629315#comment-16629315
]
ASF subversion and git services commented on ISIS-1976:
---
Commit f1a89a43c71fd3b370102bca456677355bd92f58 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=f1a89a4 ]
ISIS-1976: remove deprecated PropertyLayoutData.renderedAsDayBefore
fixes GridSystemServiceAbstract.setRenderedAsDayBeforeIfAny being
ignored
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/maste
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16629313#comment-16629313
]
ASF subversion and git services commented on ISIS-1976:
---
Commit a1fdfa45fddd0a8bcf9781a222d5e63a7fdb903d in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=a1fdfa4 ]
ISIS-1976: remove deprecated BookmarkService methods that don't take a
FieldResetPolicy argument
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16629319#comment-16629319
]
ASF subversion and git services commented on ISIS-1976:
---
Commit 9283f47adf2491e70da1c042f31011038f1ad591 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=9283f47 ]
ISIS-1976: remove deprecated MetaModelServce.sortOf methods not having
the Mode argument
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/apa
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16629316#comment-16629316
]
ASF subversion and git services commented on ISIS-1976:
---
Commit bb045b1ae3be3b0689f6def9c0c87282bcdbd982 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=bb045b1 ]
ISIS-1976: remove deprecated bulk actions
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/persistenc
[jira] [Commented] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16629317#comment-16629317
]
ASF subversion and git services commented on ISIS-1976:
---
Commit bb045b1ae3be3b0689f6def9c0c87282bcdbd982 in isis's branch refs/heads/v2
from [~hobrom]
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=bb045b1 ]
ISIS-1976: remove deprecated bulk actions
Task-Url: https://issues.apache.org/jira/browse/ISIS-1976
> 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/persistenc
