Index on Region
>From the cache-1.0.xsd, we noticed that an index can have element like "functional" and "primary-key", but the docs did not mention anything about it ( https://geode.apache.org/docs/guide/13/reference/topics/cache_xml.html#region). I am wondering if these are deprecated? Would it be better for the the xml created by the cluster configuration not consist any of these? A functional type of index needs a from-clause, expression which are mandatory. The import string is used for specifying the type of Object in the region or the type of Object which the indexed expression evaluates to. A primary-key type of index needs a field attribute which is mandatory. There should be only one or zero primary-index defined for a region -- Cheers Jinmei
Re: Index on Region
Hi Jinmei, I am not sure whether these elements were deprecated or not. I know that they were at one time valid and a user could specify the following in their app at one point: I believe the "new" way to do this would be: How would deprecation for this work? Would your roll a new version of the new definition/scheme? On Mon, Apr 16, 2018 at 10:28 AM Jinmei Liao wrote: > From the cache-1.0.xsd, we noticed that an index can have element like > "functional" and "primary-key", but the docs did not mention anything about > it ( > > https://geode.apache.org/docs/guide/13/reference/topics/cache_xml.html#region > ). > I am wondering if these are deprecated? Would it be better for the the xml > created by the cluster configuration not consist any of these? > > > > > > A functional type of index needs a from-clause, expression > which are mandatory. > The import string is used for specifying the type of Object in > the region or > the type of Object which the indexed expression evaluates to. > > > > > > > > > > > > > A primary-key type of index needs a field attribute which is > mandatory. > There should be only one or zero primary-index defined for a region > > > > > > > > > > > -- > Cheers > > Jinmei >
Geode unit tests completed in 'develop/FlakyTest' with non-zero exit code
Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/429
Re: Index on Region
I don't think we have a process for deprecating elements in cache.xml yet All the changes we've had so far are additions, not removal. The reason I am asking is that we are creating POJO's (started by JAXB tool from xsd file) that would generate the cluster configuration xml automatically. As long as we know there are "new" ways to do things, we should have these POJO's only generate XML that's in the new style. Thanks! On Mon, Apr 16, 2018 at 12:01 PM, Jason Huynh wrote: > Hi Jinmei, > > I am not sure whether these elements were deprecated or not. I know that > they were at one time valid and a user could specify the following in their > app at one point: > > > > > > I believe the "new" way to do this would be: > > > > How would deprecation for this work? Would your roll a new version of > the new definition/scheme? > > > On Mon, Apr 16, 2018 at 10:28 AM Jinmei Liao wrote: > > > From the cache-1.0.xsd, we noticed that an index can have element like > > "functional" and "primary-key", but the docs did not mention anything > about > > it ( > > > > https://geode.apache.org/docs/guide/13/reference/topics/ > cache_xml.html#region > > ). > > I am wondering if these are deprecated? Would it be better for the the > xml > > created by the cluster configuration not consist any of these? > > > > > > > > > > > > A functional type of index needs a from-clause, expression > > which are mandatory. > > The import string is used for specifying the type of Object in > > the region or > > the type of Object which the indexed expression evaluates to. > > > > > > > >/> > >/> > > > > > > > > > > > > > > > > A primary-key type of index needs a field attribute which is > > mandatory. > > There should be only one or zero primary-index defined for a > region > > > > > > > > > > > > > > > > > > > > > > -- > > Cheers > > > > Jinmei > > > -- Cheers Jinmei
Re: Index on Region
Some types / fields have their deprecation noted in their documentation, within the block. Alternatively / in addition, some xsd:element have the block deprecated Although I don't know if these annotations count as "visible," but they are there. On Mon, Apr 16, 2018 at 1:49 PM, Jinmei Liao wrote: > I don't think we have a process for deprecating elements in cache.xml > yet All the changes we've had so far are additions, not removal. > > The reason I am asking is that we are creating POJO's (started by JAXB tool > from xsd file) that would generate the cluster configuration xml > automatically. As long as we know there are "new" ways to do things, we > should have these POJO's only generate XML that's in the new style. > > Thanks! > > On Mon, Apr 16, 2018 at 12:01 PM, Jason Huynh wrote: > > > Hi Jinmei, > > > > I am not sure whether these elements were deprecated or not. I know that > > they were at one time valid and a user could specify the following in > their > > app at one point: > > > > > > > > > > > > I believe the "new" way to do this would be: > > > > > > > > How would deprecation for this work? Would your roll a new version of > > the new definition/scheme? > > > > > > On Mon, Apr 16, 2018 at 10:28 AM Jinmei Liao wrote: > > > > > From the cache-1.0.xsd, we noticed that an index can have element like > > > "functional" and "primary-key", but the docs did not mention anything > > about > > > it ( > > > > > > https://geode.apache.org/docs/guide/13/reference/topics/ > > cache_xml.html#region > > > ). > > > I am wondering if these are deprecated? Would it be better for the the > > xml > > > created by the cluster configuration not consist any of these? > > > > > > > > > > > > > > > > > > A functional type of index needs a from-clause, expression > > > which are mandatory. > > > The import string is used for specifying the type of Object in > > > the region or > > > the type of Object which the indexed expression evaluates to. > > > > > > > > > > > >> /> > > >use="required" > > /> > > > > > > > > > > > > > > > > > > > > > > > > A primary-key type of index needs a field attribute which is > > > mandatory. > > > There should be only one or zero primary-index defined for a > > region > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Cheers > > > > > > Jinmei > > > > > > > > > -- > Cheers > > Jinmei >
Re: Index on Region
Simply searching "deprecated" in cache-1.0.xsd, we have 15 hits. Would it make sense to start creating a cache-2.0.xsd? or better yet, a server-cache-2.0.xsd and a client-cache-2.0.xsd? On Mon, Apr 16, 2018 at 2:55 PM, Patrick Rhomberg wrote: > Some types / fields have their deprecation noted in their documentation, > within the block. Alternatively / in addition, some > xsd:element have the block > > > deprecated > > > > Although I don't know if these annotations count as "visible," but they are > there. > > On Mon, Apr 16, 2018 at 1:49 PM, Jinmei Liao wrote: > > > I don't think we have a process for deprecating elements in cache.xml > > yet All the changes we've had so far are additions, not removal. > > > > The reason I am asking is that we are creating POJO's (started by JAXB > tool > > from xsd file) that would generate the cluster configuration xml > > automatically. As long as we know there are "new" ways to do things, we > > should have these POJO's only generate XML that's in the new style. > > > > Thanks! > > > > On Mon, Apr 16, 2018 at 12:01 PM, Jason Huynh wrote: > > > > > Hi Jinmei, > > > > > > I am not sure whether these elements were deprecated or not. I know > that > > > they were at one time valid and a user could specify the following in > > their > > > app at one point: > > > > > > > > > > > > > > > > > > I believe the "new" way to do this would be: > > > > > > > > > > > > How would deprecation for this work? Would your roll a new version of > > > the new definition/scheme? > > > > > > > > > On Mon, Apr 16, 2018 at 10:28 AM Jinmei Liao > wrote: > > > > > > > From the cache-1.0.xsd, we noticed that an index can have element > like > > > > "functional" and "primary-key", but the docs did not mention anything > > > about > > > > it ( > > > > > > > > https://geode.apache.org/docs/guide/13/reference/topics/ > > > cache_xml.html#region > > > > ). > > > > I am wondering if these are deprecated? Would it be better for the > the > > > xml > > > > created by the cluster configuration not consist any of these? > > > > > > > > > > > > > > > > > > > > > > > > A functional type of index needs a from-clause, expression > > > > which are mandatory. > > > > The import string is used for specifying the type of Object > in > > > > the region or > > > > the type of Object which the indexed expression evaluates to. > > > > > > > > > > > > > > > >use="required" > > > /> > > > >> use="required" > > > /> > > > >/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > A primary-key type of index needs a field attribute which is > > > > mandatory. > > > > There should be only one or zero primary-index defined for a > > > region > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Cheers > > > > > > > > Jinmei > > > > > > > > > > > > > > > -- > > Cheers > > > > Jinmei > > > -- Cheers Jinmei
Re: Index on Region
We should probably target removal of the "deprecated" cache xsd types/elements in Geode 2.0. I'm not sure if we can introduce cache-2.0.xsd before Geode 2.0 or not (anyone know?). On Mon, Apr 16, 2018 at 2:59 PM, Jinmei Liao wrote: > Simply searching "deprecated" in cache-1.0.xsd, we have 15 hits. Would it > make sense to start creating a cache-2.0.xsd? or better yet, a > server-cache-2.0.xsd and a client-cache-2.0.xsd? > > > On Mon, Apr 16, 2018 at 2:55 PM, Patrick Rhomberg > wrote: > > > Some types / fields have their deprecation noted in their documentation, > > within the block. Alternatively / in addition, some > > xsd:element have the block > > > > > > deprecated > > > > > > > > Although I don't know if these annotations count as "visible," but they > are > > there. > > > > On Mon, Apr 16, 2018 at 1:49 PM, Jinmei Liao wrote: > > > > > I don't think we have a process for deprecating elements in cache.xml > > > yet All the changes we've had so far are additions, not removal. > > > > > > The reason I am asking is that we are creating POJO's (started by JAXB > > tool > > > from xsd file) that would generate the cluster configuration xml > > > automatically. As long as we know there are "new" ways to do things, we > > > should have these POJO's only generate XML that's in the new style. > > > > > > Thanks! > > > > > > On Mon, Apr 16, 2018 at 12:01 PM, Jason Huynh > wrote: > > > > > > > Hi Jinmei, > > > > > > > > I am not sure whether these elements were deprecated or not. I know > > that > > > > they were at one time valid and a user could specify the following in > > > their > > > > app at one point: > > > > > > > > > > > > > > > > > > > > > > > > I believe the "new" way to do this would be: > > > > > > > > expression="ID"/> > > > > > > > > How would deprecation for this work? Would your roll a new version of > > > > the new definition/scheme? > > > > > > > > > > > > On Mon, Apr 16, 2018 at 10:28 AM Jinmei Liao > > wrote: > > > > > > > > > From the cache-1.0.xsd, we noticed that an index can have element > > like > > > > > "functional" and "primary-key", but the docs did not mention > anything > > > > about > > > > > it ( > > > > > > > > > > https://geode.apache.org/docs/guide/13/reference/topics/ > > > > cache_xml.html#region > > > > > ). > > > > > I am wondering if these are deprecated? Would it be better for the > > the > > > > xml > > > > > created by the cluster configuration not consist any of these? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A functional type of index needs a from-clause, expression > > > > > which are mandatory. > > > > > The import string is used for specifying the type of Object > > in > > > > > the region or > > > > > the type of Object which the indexed expression evaluates > to. > > > > > > > > > > > > > > > > > > > >> use="required" > > > > /> > > > > >> > use="required" > > > > /> > > > > >use="optional" > > /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A primary-key type of index needs a field attribute which > is > > > > > mandatory. > > > > > There should be only one or zero primary-index defined for > a > > > > region > > > > > > > > > > > > > > > > > > > >/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Cheers > > > > > > > > > > Jinmei > > > > > > > > > > > > > > > > > > > > > -- > > > Cheers > > > > > > Jinmei > > > > > > > > > -- > Cheers > > Jinmei >
Geode unit tests completed in 'release-1.6.0/DistributedTest' with non-zero exit code
Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/release-1.6.0/jobs/DistributedTest/builds/5
[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #889 was SUCCESSFUL (with 2384 tests)
--- Spring Data GemFire > Nightly-ApacheGeode > #889 was successful. --- Scheduled 2386 tests in total. https://build.spring.io/browse/SGF-NAG-889/ -- This message is automatically generated by Atlassian Bamboo
Re: [Proposal] geode-dunit sub module.
+1 For a cleaner public dunit API. I am changing my proposal to rather create "geode-test" sub-module by combining geode-junit, geode-old-versions, and dunit test framework(extracted from geode-core). For eclipse users, I would recommend the use of buildship (rather than gradle eclipse plugin) and buildship currently suggests[1] to change the level to a warning and ignore any cyclic dependencies. [1] https://github.com/eclipse/buildship/issues/460 On Thu, Apr 5, 2018 at 1:32 PM, Dan Smith wrote: > +1 Seems like great idea! > > A couple thoughts - I think it would help our users if we make dunit API > very clean and abide by our backwards compatibility rules for that API as > well. It would suck to write a test suite that keeps breaking on every > version of geode. > > I think you still might run into some build complications since geode-core > source and tests are in the same module. Especially for people running > eclipse, since it combines src and test into the same source set (at least > last I checked). I'm sure there is some way to make it work though. > > -Dan > > On Thu, Apr 5, 2018 at 12:50 PM, Sai Boorlagadda < > sai_boorlaga...@apache.org > > wrote: > > > All, > > > > Geode's dunit framework can provide an easier way to write integration > > tests for any server-side extensions or server-side application code. > > Currently the dunit framework is not a published artifact, so developers > > cannot write distributed tests. So the proposal is to move all dunit > > framework to 'geode-dunit' sub-module while leaving distributed tests > > themselves in geode-core. Also by limiting the scope to 'testCompile' > there > > is no cyclic dependency between core and this new module. > > > > AFAIK, there are couple of ways users can write integration tests: > > > > - Use gradle to setup test infrastructure, geode-examples demonstrates > > this effort. > > - Use 'GeodeIntegrationTestPlugin` gradle plugin[1]. > > > > While both these approaches would be sufficient for most of the > application > > developers, it limits geode extension developers as the assertions can > > solely on the APIs. Having dunit framework published to maven can help > > these developers to write distributed unit tests just like the core > > product. > > > > [1] https://cwiki.apache.org/confluence/display/GEODE/Test+ > > your+application > > > > Please let me know your thoughts. > > > > Sai > > >
Re: [Proposal] geode-dunit sub module.
+1 I think I'm in favor of all of these changes as well. I don't know anything about buildship though. I do have a few dunit changes on a feature branch that I'd like to get merged to develop before we move dunit out of geode-core. I'll try to wrap up these changes by Tues or Wed. On Mon, Apr 16, 2018 at 4:11 PM, Sai Boorlagadda wrote: > +1 For a cleaner public dunit API. > > I am changing my proposal to rather create "geode-test" sub-module by > combining geode-junit, geode-old-versions, and dunit test > framework(extracted from geode-core). > > For eclipse users, I would recommend the use of buildship (rather than > gradle eclipse plugin) and buildship currently suggests[1] to change the > level to a warning and ignore any cyclic dependencies. > > [1] https://github.com/eclipse/buildship/issues/460 > > On Thu, Apr 5, 2018 at 1:32 PM, Dan Smith wrote: > > > +1 Seems like great idea! > > > > A couple thoughts - I think it would help our users if we make dunit API > > very clean and abide by our backwards compatibility rules for that API as > > well. It would suck to write a test suite that keeps breaking on every > > version of geode. > > > > I think you still might run into some build complications since > geode-core > > source and tests are in the same module. Especially for people running > > eclipse, since it combines src and test into the same source set (at > least > > last I checked). I'm sure there is some way to make it work though. > > > > -Dan > > > > On Thu, Apr 5, 2018 at 12:50 PM, Sai Boorlagadda < > > sai_boorlaga...@apache.org > > > wrote: > > > > > All, > > > > > > Geode's dunit framework can provide an easier way to write integration > > > tests for any server-side extensions or server-side application code. > > > Currently the dunit framework is not a published artifact, so > developers > > > cannot write distributed tests. So the proposal is to move all dunit > > > framework to 'geode-dunit' sub-module while leaving distributed tests > > > themselves in geode-core. Also by limiting the scope to 'testCompile' > > there > > > is no cyclic dependency between core and this new module. > > > > > > AFAIK, there are couple of ways users can write integration tests: > > > > > > - Use gradle to setup test infrastructure, geode-examples demonstrates > > > this effort. > > > - Use 'GeodeIntegrationTestPlugin` gradle plugin[1]. > > > > > > While both these approaches would be sufficient for most of the > > application > > > developers, it limits geode extension developers as the assertions can > > > solely on the APIs. Having dunit framework published to maven can help > > > these developers to write distributed unit tests just like the core > > > product. > > > > > > [1] https://cwiki.apache.org/confluence/display/GEODE/Test+ > > > your+application > > > > > > Please let me know your thoughts. > > > > > > Sai > > > > > >
Geode unit tests completed in 'develop/FlakyTest' with non-zero exit code
Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/432
