Re: Index on Region

XSD versions have always matched the version of the GemFire release. Starting with Geode 1.0, the XSD version was matched up with Geode release. So, for example, if we need to introduce a new XSD in Geode 1.7, then it should be named geode-1.7.xsd. On Tue, Apr 17, 2018 at 8:55 AM, John Blum wrote

Re: Index on Region

Well, the way I handle this in *Spring Data for Apache Geode* is, and to *Kirk's* point, the schema (XSD) version matches the SDG version. I.e. in SDG 2.0.0 [1] there is a spring-geode-2.0.0.xsd, and in SDG 2.1.0 [2] there now exists a spring-geode-2.1.0.xsd. So, you could have a cache-1.1.xsd, o

Re: Index on Region

but our xsd is versioned. If user wants to use a more "correct" xsd when they are creating a cache.xml file, should we allow them to reference a cache-2.0.xsd instead of cache-1.0.xsd? (provided that 2.0 is only a washed down version of 1.0, nothing new added). On Tue, Apr 17, 2018 at 8:28 AM, Mic

Re: Index on Region

Correct. We can "deprecate" any time we like as long as we have provided an alternative, but we should only "remove" on a major release. -- Mike Stolz Principal Engineer, GemFire Product Lead Mobile: +1-631-835-4771 Download the new GemFire book here.

Re: Index on Region

They way it works now is that our xsd, xml parser and xml generator are disconnected. The xsd file is only used by the xml editor when editing the xml. The parser is parsing everything allowed by xsd, but it's not generated by xsd. The XML generated by our generator is not validated using the xsd e

Re: Index on Region

Deprecation is a signal that a user should begin migrating to an alternative because that thing may be removed in a future release. Following the SemVer practice gives our users confidence that we won’t break stuff in a minor release. Anthony > On Apr 16, 2018, at 3:11 PM, Kirk Lund wrote:

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 hit

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 i

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 Lia

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

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 vers

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