[jira] [Commented] (ISIS-2020) DataNucleus Federated Datastore functionality not used in query
[
https://issues.apache.org/jira/browse/ISIS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678672#comment-16678672
]
Brian Kalbfus commented on ISIS-2020:
-
When I change
{code:java}
return repositoryService.allInstances(HelloOtherWorldObject.class);{code}
to
{code:java}
return isisJdoSupport.executeQuery(HelloOtherWorldObject.class, null);{code}
then the result looks good to me. Is there a good reason to prefer
repositoryService#allInstances over doing a query like this?
> DataNucleus Federated Datastore functionality not used in query
> ---
>
> Key: ISIS-2020
> URL: https://issues.apache.org/jira/browse/ISIS-2020
> Project: Isis
> Issue Type: Bug
> Components: Core: Objectstore: JDO
>Affects Versions: 1.16.2, 2.0.0-M1
>Reporter: Brian Kalbfus
>Assignee: Andi Huber
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: datanucleus-api-jdo.patch
>
>
> Insert and Update operations work as expected, but query operations operate
> on the primary datastore. I see from stepping through the M1 code that
> Insert and Update operations use a transaction that accesses a
> FederatedDataStore. I guess that is where the difference occurs in that the
> query operations get a data store another way, failing to get the
> FederatedDataStore that is configured.
> example code created from helloworld-archetype is at
> [https://github.com/bkalbfus/isis-federatedDS-2_0_0-M1]
> Mailing list:
> [https://lists.apache.org/thread.html/2edea2f8d802532c3672eddc83b484bbc2e31d1cac16f2759feeb95f@%3Cusers.isis.apache.org%3E]
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (ISIS-2030) Table Column Order: use order of occurrence in layout grid as the default
[ https://issues.apache.org/jira/browse/ISIS-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andi Huber closed ISIS-2030. Resolution: Fixed implemented; no works like I believe it was prior to v2 > Table Column Order: use order of occurrence in layout grid as the default > - > > Key: ISIS-2030 > URL: https://issues.apache.org/jira/browse/ISIS-2030 > Project: Isis > Issue Type: Improvement > Components: Core: Viewer: Wicket >Reporter: Andi Huber >Assignee: Andi Huber >Priority: Major > Fix For: 2.0.0-M2 > > > Instead of ordering by column name (more precisely: propertyId), use the grid > layout facet: > 1) if propertyId is mentioned within grid, put into first 'half' ordered by > occurrence within grid. > 2) if propertyId is not mentioned within grid, put into second 'half' ordered > by propertyId (String) in natural order -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ISIS-2030) Table Column Order: use order of occurrence in layout grid as the default
[ https://issues.apache.org/jira/browse/ISIS-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678623#comment-16678623 ] ASF subversion and git services commented on ISIS-2030: --- Commit 2f8f57c32e3a85c54c35c9d73062e8212bb4c8e5 in isis's branch refs/heads/v2 from [~hobrom] [ https://gitbox.apache.org/repos/asf?p=isis.git;h=2f8f57c ] ISIS-2030: utilizes the grid facet to reorder table columns Task-Url: https://issues.apache.org/jira/browse/ISIS-2030 > Table Column Order: use order of occurrence in layout grid as the default > - > > Key: ISIS-2030 > URL: https://issues.apache.org/jira/browse/ISIS-2030 > Project: Isis > Issue Type: Improvement > Components: Core: Viewer: Wicket >Reporter: Andi Huber >Assignee: Andi Huber >Priority: Major > Fix For: 2.0.0-M2 > > > Instead of ordering by column name (more precisely: propertyId), use the grid > layout facet: > 1) if propertyId is mentioned within grid, put into first 'half' ordered by > occurrence within grid. > 2) if propertyId is not mentioned within grid, put into second 'half' ordered > by propertyId (String) in natural order -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ISIS-2030) Table Column Order: use order of occurrence in layout grid as the default
[ https://issues.apache.org/jira/browse/ISIS-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678624#comment-16678624 ] ASF subversion and git services commented on ISIS-2030: --- Commit 2f8f57c32e3a85c54c35c9d73062e8212bb4c8e5 in isis's branch refs/heads/v2 from [~hobrom] [ https://gitbox.apache.org/repos/asf?p=isis.git;h=2f8f57c ] ISIS-2030: utilizes the grid facet to reorder table columns Task-Url: https://issues.apache.org/jira/browse/ISIS-2030 > Table Column Order: use order of occurrence in layout grid as the default > - > > Key: ISIS-2030 > URL: https://issues.apache.org/jira/browse/ISIS-2030 > Project: Isis > Issue Type: Improvement > Components: Core: Viewer: Wicket >Reporter: Andi Huber >Assignee: Andi Huber >Priority: Major > Fix For: 2.0.0-M2 > > > Instead of ordering by column name (more precisely: propertyId), use the grid > layout facet: > 1) if propertyId is mentioned within grid, put into first 'half' ordered by > occurrence within grid. > 2) if propertyId is not mentioned within grid, put into second 'half' ordered > by propertyId (String) in natural order -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ISIS-2030) Table Column Order: use order of occurrence in layout grid as the default
[ https://issues.apache.org/jira/browse/ISIS-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andi Huber updated ISIS-2030: - Summary: Table Column Order: use order of occurrence in layout grid as the default (was: Table Column Order: use order of occurence in layout grid as the default) > Table Column Order: use order of occurrence in layout grid as the default > - > > Key: ISIS-2030 > URL: https://issues.apache.org/jira/browse/ISIS-2030 > Project: Isis > Issue Type: Improvement > Components: Core: Viewer: Wicket >Reporter: Andi Huber >Assignee: Andi Huber >Priority: Major > Fix For: 2.0.0-M2 > > > Instead of ordering by column name (more precisely: propertyId), use the grid > layout facet: > 1) if propertyId is mentioned within grid, put into first 'half' ordered by > occurrence within grid. > 2) if propertyId is not mentioned within grid, put into second 'half' ordered > by propertyId (String) in natural order -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ISIS-2030) Table Column Order: use order of occurence in layout grid as the default
Andi Huber created ISIS-2030: Summary: Table Column Order: use order of occurence in layout grid as the default Key: ISIS-2030 URL: https://issues.apache.org/jira/browse/ISIS-2030 Project: Isis Issue Type: Improvement Components: Core: Viewer: Wicket Reporter: Andi Huber Assignee: Andi Huber Fix For: 2.0.0-M2 Instead of ordering by column name (more precisely: propertyId), use the grid layout facet: 1) if propertyId is mentioned within grid, put into first 'half' ordered by occurrence within grid. 2) if propertyId is not mentioned within grid, put into second 'half' ordered by propertyId (String) in natural order -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (ISIS-2020) DataNucleus Federated Datastore functionality not used in query
[ https://issues.apache.org/jira/browse/ISIS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678099#comment-16678099 ] Andi Huber edited comment on ISIS-2020 at 11/7/18 11:51 AM: As it stands, there is no easy fix to this (see Details below). For now we simply don't support Data Federation [1], as this feature is still 'experimental' with Datanucleus. DN does recommend to use multiple Persistence Managers instead, which is also not yet supported by Apache Isis. There is a lot of work involved with getting there, which is also related to our vision of supporting JPA as an alternative persistence layer, which requires decoupling from DN. I'm afraid, this issue will take some time to get resolved. +Details:+ We are programmatically modifying DN properties, when bootstrapping Apache Isis. We are overriding those that are read in from property files. We do this to handle schema creation. However, DN's FederatedStoreManager does not allow this approach for secondary properties. It seems we would need DN to extend its API in order for us to hook in as we do with the SchemaAwareStoreManager. [1] http://www.datanucleus.org/products/datanucleus/jdo/persistence.html#data_federation was (Author: hobrom): As it stands, there is no easy fix to this (see Details below). For now we simply don't support Data Federation [1], as this feature is still 'experimental' with Datanucleus. DN does recommend to use multiple Persistence Managers instead, which is also not yet supported by Apache Isis. There is a lot of work involved with getting there, which is also related to our vision of supporting JPA as an alternative persistence layer, which requires decoupling from DN. I'm afraid, this issue will take some time to get resolved. +Details:+ We are programmatically modifying DN properties, when bootstrapping Apache Isis. We are overriding those that are read in from property files. We do this to handle schema creation. However, DN's FederatedStoreManager does not allow this approach for secondary properties. I seems we would need DN to extend its API in order for us to hook in as we do with the SchemaAwareStoreManager. [1] http://www.datanucleus.org/products/datanucleus/jdo/persistence.html#data_federation > DataNucleus Federated Datastore functionality not used in query > --- > > Key: ISIS-2020 > URL: https://issues.apache.org/jira/browse/ISIS-2020 > Project: Isis > Issue Type: Bug > Components: Core: Objectstore: JDO >Affects Versions: 1.16.2, 2.0.0-M1 >Reporter: Brian Kalbfus >Assignee: Andi Huber >Priority: Major > Fix For: 2.0.0 > > Attachments: datanucleus-api-jdo.patch > > > Insert and Update operations work as expected, but query operations operate > on the primary datastore. I see from stepping through the M1 code that > Insert and Update operations use a transaction that accesses a > FederatedDataStore. I guess that is where the difference occurs in that the > query operations get a data store another way, failing to get the > FederatedDataStore that is configured. > example code created from helloworld-archetype is at > [https://github.com/bkalbfus/isis-federatedDS-2_0_0-M1] > Mailing list: > [https://lists.apache.org/thread.html/2edea2f8d802532c3672eddc83b484bbc2e31d1cac16f2759feeb95f@%3Cusers.isis.apache.org%3E] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (ISIS-2020) DataNucleus Federated Datastore functionality not used in query
[ https://issues.apache.org/jira/browse/ISIS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678099#comment-16678099 ] Andi Huber edited comment on ISIS-2020 at 11/7/18 11:50 AM: As it stands, there is no easy fix to this (see Details below). For now we simply don't support Data Federation [1], as this feature is still 'experimental' with Datanucleus. DN does recommend to use multiple Persistence Managers instead, which is also not yet supported by Apache Isis. There is a lot of work involved with getting there, which is also related to our vision of supporting JPA as an alternative persistence layer, which requires decoupling from DN. I'm afraid, this issue will take some time to get resolved. +Details:+ We are programmatically modifying DN properties, when bootstrapping Apache Isis. We are overriding those that are read in from property files. We do this to handle schema creation. However, DN's FederatedStoreManager does not allow this approach for secondary properties. I seems we would need DN to extend its API in order for us to hook in as we do with the SchemaAwareStoreManager. [1] http://www.datanucleus.org/products/datanucleus/jdo/persistence.html#data_federation was (Author: hobrom): As it stands, there is no easy fix to this (see Details below). For now we simply don't support Data Federation [1], as this feature is still 'experimental' with Datanucleus. DN does recommend to use multiple Persistence Managers instead, which is also not yet supported by Apache Isis. There is a lot of work involved with getting there, which is also related to our vision of supporting JPA as an alternative persistence layer, which requires decoupling from DN. I'm afraid, this issue will take some time to get resolved. +Details:+ We are programmatically modifying DN properties, when bootstrapping Apache Isis. We are overriding those that are read in from property files. We do this to handle schema creation. However, DN's FederatedStoreManager does not allow this approach for secondary properties. I seems would need DN to extends its API in order for us to hook in as we do with the SchemaAwareStoreManager. [1] http://www.datanucleus.org/products/datanucleus/jdo/persistence.html#data_federation > DataNucleus Federated Datastore functionality not used in query > --- > > Key: ISIS-2020 > URL: https://issues.apache.org/jira/browse/ISIS-2020 > Project: Isis > Issue Type: Bug > Components: Core: Objectstore: JDO >Affects Versions: 1.16.2, 2.0.0-M1 >Reporter: Brian Kalbfus >Assignee: Andi Huber >Priority: Major > Fix For: 2.0.0 > > Attachments: datanucleus-api-jdo.patch > > > Insert and Update operations work as expected, but query operations operate > on the primary datastore. I see from stepping through the M1 code that > Insert and Update operations use a transaction that accesses a > FederatedDataStore. I guess that is where the difference occurs in that the > query operations get a data store another way, failing to get the > FederatedDataStore that is configured. > example code created from helloworld-archetype is at > [https://github.com/bkalbfus/isis-federatedDS-2_0_0-M1] > Mailing list: > [https://lists.apache.org/thread.html/2edea2f8d802532c3672eddc83b484bbc2e31d1cac16f2759feeb95f@%3Cusers.isis.apache.org%3E] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ISIS-2020) DataNucleus Federated Datastore functionality not used in query
[ https://issues.apache.org/jira/browse/ISIS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678099#comment-16678099 ] Andi Huber commented on ISIS-2020: -- As it stands, there is no easy fix to this (see Details below). For now we simply don't support Data Federation [1], as this feature is still 'experimental' with Datanucleus. DN does recommend to use multiple Persistence Managers instead, which is also not yet supported by Apache Isis. There is a lot of work involved with getting there, which is also related to our vision of supporting JPA as an alternative persistence layer, which requires decoupling from DN. I'm afraid, this issue will take some time to get resolved. +Details:+ We are programmatically modifying DN properties, when bootstrapping Apache Isis. We are overriding those that are read in from property files. We do this to handle schema creation. However, DN's FederatedStoreManager does not allow this approach for secondary properties. I seems would need DN to extends its API in order for us to hook in as we do with the SchemaAwareStoreManager. [1] http://www.datanucleus.org/products/datanucleus/jdo/persistence.html#data_federation > DataNucleus Federated Datastore functionality not used in query > --- > > Key: ISIS-2020 > URL: https://issues.apache.org/jira/browse/ISIS-2020 > Project: Isis > Issue Type: Bug > Components: Core: Objectstore: JDO >Affects Versions: 1.16.2, 2.0.0-M1 >Reporter: Brian Kalbfus >Assignee: Andi Huber >Priority: Major > Fix For: 2.0.0 > > Attachments: datanucleus-api-jdo.patch > > > Insert and Update operations work as expected, but query operations operate > on the primary datastore. I see from stepping through the M1 code that > Insert and Update operations use a transaction that accesses a > FederatedDataStore. I guess that is where the difference occurs in that the > query operations get a data store another way, failing to get the > FederatedDataStore that is configured. > example code created from helloworld-archetype is at > [https://github.com/bkalbfus/isis-federatedDS-2_0_0-M1] > Mailing list: > [https://lists.apache.org/thread.html/2edea2f8d802532c3672eddc83b484bbc2e31d1cac16f2759feeb95f@%3Cusers.isis.apache.org%3E] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ISIS-2020) DataNucleus Federated Datastore functionality not used in query
[ https://issues.apache.org/jira/browse/ISIS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andi Huber updated ISIS-2020: - Fix Version/s: (was: 2.0.0-M2) 2.0.0 > DataNucleus Federated Datastore functionality not used in query > --- > > Key: ISIS-2020 > URL: https://issues.apache.org/jira/browse/ISIS-2020 > Project: Isis > Issue Type: Bug > Components: Core: Objectstore: JDO >Affects Versions: 1.16.2, 2.0.0-M1 >Reporter: Brian Kalbfus >Assignee: Andi Huber >Priority: Major > Fix For: 2.0.0 > > Attachments: datanucleus-api-jdo.patch > > > Insert and Update operations work as expected, but query operations operate > on the primary datastore. I see from stepping through the M1 code that > Insert and Update operations use a transaction that accesses a > FederatedDataStore. I guess that is where the difference occurs in that the > query operations get a data store another way, failing to get the > FederatedDataStore that is configured. > example code created from helloworld-archetype is at > [https://github.com/bkalbfus/isis-federatedDS-2_0_0-M1] > Mailing list: > [https://lists.apache.org/thread.html/2edea2f8d802532c3672eddc83b484bbc2e31d1cac16f2759feeb95f@%3Cusers.isis.apache.org%3E] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ISIS-2020) DataNucleus Federated Datastore functionality not used in query
[ https://issues.apache.org/jira/browse/ISIS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677801#comment-16677801 ] ASF subversion and git services commented on ISIS-2020: --- Commit 95b4b404e98ee03a8303bb20007991eb7537bc0a in isis's branch refs/heads/v2 from [~hobrom] [ https://gitbox.apache.org/repos/asf?p=isis.git;h=95b4b40 ] ISIS-2020: update to latest DataNucleus dn5-jdo-api.version -> 3.2.0-m10 dn5-core.version -> 5.2.0-m2 dn5-api-jdo.version -> 5.2.0-m2 dn5-jdo-query.version -> 5.0.8 dn5-rdbms.version -> 5.2.0-m2 dn5-jodatime.version -> 5.2.0-m1 also dealing with the fact, that some DN classes and methods have been renamed Task-Url: https://issues.apache.org/jira/browse/ISIS-2020 > DataNucleus Federated Datastore functionality not used in query > --- > > Key: ISIS-2020 > URL: https://issues.apache.org/jira/browse/ISIS-2020 > Project: Isis > Issue Type: Bug > Components: Core: Objectstore: JDO >Affects Versions: 1.16.2, 2.0.0-M1 >Reporter: Brian Kalbfus >Assignee: Andi Huber >Priority: Major > Fix For: 2.0.0-M2 > > Attachments: datanucleus-api-jdo.patch > > > Insert and Update operations work as expected, but query operations operate > on the primary datastore. I see from stepping through the M1 code that > Insert and Update operations use a transaction that accesses a > FederatedDataStore. I guess that is where the difference occurs in that the > query operations get a data store another way, failing to get the > FederatedDataStore that is configured. > example code created from helloworld-archetype is at > [https://github.com/bkalbfus/isis-federatedDS-2_0_0-M1] > Mailing list: > [https://lists.apache.org/thread.html/2edea2f8d802532c3672eddc83b484bbc2e31d1cac16f2759feeb95f@%3Cusers.isis.apache.org%3E] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
