You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Jinmei Liao <ji...@pivotal.io> on 2018/04/16 17:28:02 UTC
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?
<xsd:choice minOccurs="0">
<xsd:element name="functional">
<xsd:annotation>
<xsd:documentation>
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.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:attribute name="expression" type="xsd:string" use="required" />
<xsd:attribute name="from-clause" type="xsd:string" use="required" />
<xsd:attribute name="imports" type="xsd:string" use="optional" />
</xsd:complexType>
</xsd:element>
<xsd:element name="primary-key">
<xsd:annotation>
<xsd:documentation>
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
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:attribute name="field" type="xsd:string" use="required" />
</xsd:complexType>
</xsd:element>
</xsd:choice>
--
Cheers
Jinmei
Re: Index on Region
Posted by Jinmei Liao <ji...@pivotal.io>.
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 either. So technically, if we are only to remove
element/attributes, i.e. create a more restrictive xsd, and have our
cluster configuration generated by a "washed down version" of the xsd,
then our parser would not break at all.
On Tue, Apr 17, 2018 at 7:51 AM, Anthony Baker <ab...@pivotal.io> wrote:
> 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 <kl...@apache.org> wrote:
> >
> > 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 <ji...@pivotal.io> 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 <prhomberg@pivotal.io
> >
> >> wrote:
> >>
> >>> Some types / fields have their deprecation noted in their
> documentation,
> >>> within the <xsd:documentation> block. Alternatively / in addition,
> some
> >>> xsd:element have the block
> >>>
> >>> <xsd:annotation>
> >>> <xsd:appinfo>deprecated</xsd:appinfo>
> >>> </xsd:annotation>
> >>>
> >>>
> >>> 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 <ji...@pivotal.io>
> 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 <jh...@pivotal.io>
> >> 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:
> >>>>>
> >>>>> <index name="pk1">
> >>>>> <primary-key field="ID"/>
> >>>>> </index>
> >>>>>
> >>>>> I believe the "new" way to do this would be:
> >>>>>
> >>>>> <index name="pk1" type="key" from-clause="/region r"
> >> 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 <ji...@pivotal.io>
> >>> 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?
> >>>>>>
> >>>>>> <xsd:choice minOccurs="0">
> >>>>>> <xsd:element name="functional">
> >>>>>> <xsd:annotation>
> >>>>>> <xsd:documentation>
> >>>>>> 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.
> >>>>>> </xsd:documentation>
> >>>>>> </xsd:annotation>
> >>>>>> <xsd:complexType>
> >>>>>> <xsd:attribute name="expression" type="xsd:string"
> >>> use="required"
> >>>>> />
> >>>>>> <xsd:attribute name="from-clause" type="xsd:string"
> >>>> use="required"
> >>>>> />
> >>>>>> <xsd:attribute name="imports" type="xsd:string"
> >> use="optional"
> >>> />
> >>>>>> </xsd:complexType>
> >>>>>> </xsd:element>
> >>>>>>
> >>>>>> <xsd:element name="primary-key">
> >>>>>> <xsd:annotation>
> >>>>>> <xsd:documentation>
> >>>>>> 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
> >>>>>> </xsd:documentation>
> >>>>>> </xsd:annotation>
> >>>>>> <xsd:complexType>
> >>>>>> <xsd:attribute name="field" type="xsd:string" use="required"
> >> />
> >>>>>> </xsd:complexType>
> >>>>>> </xsd:element>
> >>>>>> </xsd:choice>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Cheers
> >>>>>>
> >>>>>> Jinmei
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Cheers
> >>>>
> >>>> Jinmei
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> Cheers
> >>
> >> Jinmei
> >>
>
>
--
Cheers
Jinmei
Re: Index on Region
Posted by Kirk Lund <kl...@apache.org>.
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 <jb...@pivotal.io> wrote:
> 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, or a cache-1.6.xsd to match the next
> Apache Geode version. I suggest the later.
>
> If you parser is smart enough (which *Spring's* is), then you can also have
> something like this [3], which "defaults the version", when the user does
> not explicitly call out the version in an XML document instance based on
> the XSD.
>
> Food for thought,
> John
>
>
> [1]
> https://github.com/spring-projects/spring-data-geode/
> tree/2.0.6.RELEASE/src/main/resources/org/springframework/
> data/gemfire/config
> [2]
> https://github.com/spring-projects/spring-data-geode/
> tree/2.1.0.M2/src/main/resources/org/springframework/data/gemfire/config
> [3]
> https://github.com/spring-projects/spring-data-geode/
> blob/2.1.0.M2/src/main/resources/META-INF/spring.schemas
>
>
> On Tue, Apr 17, 2018 at 8:32 AM, Jinmei Liao <ji...@pivotal.io> wrote:
>
> > 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, Michael Stolz <ms...@pivotal.io>
> wrote:
> >
> > > 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.
> > > <https://content.pivotal.io/ebooks/scaling-data-services-
> > > with-pivotal-gemfire>
> > >
> > > On Tue, Apr 17, 2018 at 10:51 AM, Anthony Baker <ab...@pivotal.io>
> > wrote:
> > >
> > > > 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 <kl...@apache.org> wrote:
> > > > >
> > > > > 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 <ji...@pivotal.io>
> > > 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 <
> > > prhomberg@pivotal.io
> > > > >
> > > > >> wrote:
> > > > >>
> > > > >>> Some types / fields have their deprecation noted in their
> > > > documentation,
> > > > >>> within the <xsd:documentation> block. Alternatively / in
> addition,
> > > > some
> > > > >>> xsd:element have the block
> > > > >>>
> > > > >>> <xsd:annotation>
> > > > >>> <xsd:appinfo>deprecated</xsd:appinfo>
> > > > >>> </xsd:annotation>
> > > > >>>
> > > > >>>
> > > > >>> 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 <ji...@pivotal.io>
> > > > 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 <
> jhuynh@pivotal.io>
> > > > >> 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:
> > > > >>>>>
> > > > >>>>> <index name="pk1">
> > > > >>>>> <primary-key field="ID"/>
> > > > >>>>> </index>
> > > > >>>>>
> > > > >>>>> I believe the "new" way to do this would be:
> > > > >>>>>
> > > > >>>>> <index name="pk1" type="key" from-clause="/region r"
> > > > >> 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 <
> jiliao@pivotal.io>
> > > > >>> 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?
> > > > >>>>>>
> > > > >>>>>> <xsd:choice minOccurs="0">
> > > > >>>>>> <xsd:element name="functional">
> > > > >>>>>> <xsd:annotation>
> > > > >>>>>> <xsd:documentation>
> > > > >>>>>> 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.
> > > > >>>>>> </xsd:documentation>
> > > > >>>>>> </xsd:annotation>
> > > > >>>>>> <xsd:complexType>
> > > > >>>>>> <xsd:attribute name="expression" type="xsd:string"
> > > > >>> use="required"
> > > > >>>>> />
> > > > >>>>>> <xsd:attribute name="from-clause" type="xsd:string"
> > > > >>>> use="required"
> > > > >>>>> />
> > > > >>>>>> <xsd:attribute name="imports" type="xsd:string"
> > > > >> use="optional"
> > > > >>> />
> > > > >>>>>> </xsd:complexType>
> > > > >>>>>> </xsd:element>
> > > > >>>>>>
> > > > >>>>>> <xsd:element name="primary-key">
> > > > >>>>>> <xsd:annotation>
> > > > >>>>>> <xsd:documentation>
> > > > >>>>>> 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
> > > > >>>>>> </xsd:documentation>
> > > > >>>>>> </xsd:annotation>
> > > > >>>>>> <xsd:complexType>
> > > > >>>>>> <xsd:attribute name="field" type="xsd:string"
> > use="required"
> > > > >> />
> > > > >>>>>> </xsd:complexType>
> > > > >>>>>> </xsd:element>
> > > > >>>>>> </xsd:choice>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> --
> > > > >>>>>> Cheers
> > > > >>>>>>
> > > > >>>>>> Jinmei
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> --
> > > > >>>> Cheers
> > > > >>>>
> > > > >>>> Jinmei
> > > > >>>>
> > > > >>>
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Cheers
> > > > >>
> > > > >> Jinmei
> > > > >>
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
>
>
> --
> -John
> john.blum10101 (skype)
>
Re: Index on Region
Posted by John Blum <jb...@pivotal.io>.
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, or a cache-1.6.xsd to match the next
Apache Geode version. I suggest the later.
If you parser is smart enough (which *Spring's* is), then you can also have
something like this [3], which "defaults the version", when the user does
not explicitly call out the version in an XML document instance based on
the XSD.
Food for thought,
John
[1]
https://github.com/spring-projects/spring-data-geode/tree/2.0.6.RELEASE/src/main/resources/org/springframework/data/gemfire/config
[2]
https://github.com/spring-projects/spring-data-geode/tree/2.1.0.M2/src/main/resources/org/springframework/data/gemfire/config
[3]
https://github.com/spring-projects/spring-data-geode/blob/2.1.0.M2/src/main/resources/META-INF/spring.schemas
On Tue, Apr 17, 2018 at 8:32 AM, Jinmei Liao <ji...@pivotal.io> wrote:
> 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, Michael Stolz <ms...@pivotal.io> wrote:
>
> > 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.
> > <https://content.pivotal.io/ebooks/scaling-data-services-
> > with-pivotal-gemfire>
> >
> > On Tue, Apr 17, 2018 at 10:51 AM, Anthony Baker <ab...@pivotal.io>
> wrote:
> >
> > > 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 <kl...@apache.org> wrote:
> > > >
> > > > 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 <ji...@pivotal.io>
> > 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 <
> > prhomberg@pivotal.io
> > > >
> > > >> wrote:
> > > >>
> > > >>> Some types / fields have their deprecation noted in their
> > > documentation,
> > > >>> within the <xsd:documentation> block. Alternatively / in addition,
> > > some
> > > >>> xsd:element have the block
> > > >>>
> > > >>> <xsd:annotation>
> > > >>> <xsd:appinfo>deprecated</xsd:appinfo>
> > > >>> </xsd:annotation>
> > > >>>
> > > >>>
> > > >>> 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 <ji...@pivotal.io>
> > > 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 <jh...@pivotal.io>
> > > >> 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:
> > > >>>>>
> > > >>>>> <index name="pk1">
> > > >>>>> <primary-key field="ID"/>
> > > >>>>> </index>
> > > >>>>>
> > > >>>>> I believe the "new" way to do this would be:
> > > >>>>>
> > > >>>>> <index name="pk1" type="key" from-clause="/region r"
> > > >> 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 <ji...@pivotal.io>
> > > >>> 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?
> > > >>>>>>
> > > >>>>>> <xsd:choice minOccurs="0">
> > > >>>>>> <xsd:element name="functional">
> > > >>>>>> <xsd:annotation>
> > > >>>>>> <xsd:documentation>
> > > >>>>>> 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.
> > > >>>>>> </xsd:documentation>
> > > >>>>>> </xsd:annotation>
> > > >>>>>> <xsd:complexType>
> > > >>>>>> <xsd:attribute name="expression" type="xsd:string"
> > > >>> use="required"
> > > >>>>> />
> > > >>>>>> <xsd:attribute name="from-clause" type="xsd:string"
> > > >>>> use="required"
> > > >>>>> />
> > > >>>>>> <xsd:attribute name="imports" type="xsd:string"
> > > >> use="optional"
> > > >>> />
> > > >>>>>> </xsd:complexType>
> > > >>>>>> </xsd:element>
> > > >>>>>>
> > > >>>>>> <xsd:element name="primary-key">
> > > >>>>>> <xsd:annotation>
> > > >>>>>> <xsd:documentation>
> > > >>>>>> 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
> > > >>>>>> </xsd:documentation>
> > > >>>>>> </xsd:annotation>
> > > >>>>>> <xsd:complexType>
> > > >>>>>> <xsd:attribute name="field" type="xsd:string"
> use="required"
> > > >> />
> > > >>>>>> </xsd:complexType>
> > > >>>>>> </xsd:element>
> > > >>>>>> </xsd:choice>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> --
> > > >>>>>> Cheers
> > > >>>>>>
> > > >>>>>> Jinmei
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> Cheers
> > > >>>>
> > > >>>> Jinmei
> > > >>>>
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Cheers
> > > >>
> > > >> Jinmei
> > > >>
> > >
> > >
> >
>
>
>
> --
> Cheers
>
> Jinmei
>
--
-John
john.blum10101 (skype)
Re: Index on Region
Posted by Jinmei Liao <ji...@pivotal.io>.
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, Michael Stolz <ms...@pivotal.io> wrote:
> 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.
> <https://content.pivotal.io/ebooks/scaling-data-services-
> with-pivotal-gemfire>
>
> On Tue, Apr 17, 2018 at 10:51 AM, Anthony Baker <ab...@pivotal.io> wrote:
>
> > 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 <kl...@apache.org> wrote:
> > >
> > > 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 <ji...@pivotal.io>
> 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 <
> prhomberg@pivotal.io
> > >
> > >> wrote:
> > >>
> > >>> Some types / fields have their deprecation noted in their
> > documentation,
> > >>> within the <xsd:documentation> block. Alternatively / in addition,
> > some
> > >>> xsd:element have the block
> > >>>
> > >>> <xsd:annotation>
> > >>> <xsd:appinfo>deprecated</xsd:appinfo>
> > >>> </xsd:annotation>
> > >>>
> > >>>
> > >>> 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 <ji...@pivotal.io>
> > 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 <jh...@pivotal.io>
> > >> 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:
> > >>>>>
> > >>>>> <index name="pk1">
> > >>>>> <primary-key field="ID"/>
> > >>>>> </index>
> > >>>>>
> > >>>>> I believe the "new" way to do this would be:
> > >>>>>
> > >>>>> <index name="pk1" type="key" from-clause="/region r"
> > >> 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 <ji...@pivotal.io>
> > >>> 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?
> > >>>>>>
> > >>>>>> <xsd:choice minOccurs="0">
> > >>>>>> <xsd:element name="functional">
> > >>>>>> <xsd:annotation>
> > >>>>>> <xsd:documentation>
> > >>>>>> 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.
> > >>>>>> </xsd:documentation>
> > >>>>>> </xsd:annotation>
> > >>>>>> <xsd:complexType>
> > >>>>>> <xsd:attribute name="expression" type="xsd:string"
> > >>> use="required"
> > >>>>> />
> > >>>>>> <xsd:attribute name="from-clause" type="xsd:string"
> > >>>> use="required"
> > >>>>> />
> > >>>>>> <xsd:attribute name="imports" type="xsd:string"
> > >> use="optional"
> > >>> />
> > >>>>>> </xsd:complexType>
> > >>>>>> </xsd:element>
> > >>>>>>
> > >>>>>> <xsd:element name="primary-key">
> > >>>>>> <xsd:annotation>
> > >>>>>> <xsd:documentation>
> > >>>>>> 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
> > >>>>>> </xsd:documentation>
> > >>>>>> </xsd:annotation>
> > >>>>>> <xsd:complexType>
> > >>>>>> <xsd:attribute name="field" type="xsd:string" use="required"
> > >> />
> > >>>>>> </xsd:complexType>
> > >>>>>> </xsd:element>
> > >>>>>> </xsd:choice>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> Cheers
> > >>>>>>
> > >>>>>> Jinmei
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Cheers
> > >>>>
> > >>>> Jinmei
> > >>>>
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Cheers
> > >>
> > >> Jinmei
> > >>
> >
> >
>
--
Cheers
Jinmei
Re: Index on Region
Posted by Michael Stolz <ms...@pivotal.io>.
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.
<https://content.pivotal.io/ebooks/scaling-data-services-with-pivotal-gemfire>
On Tue, Apr 17, 2018 at 10:51 AM, Anthony Baker <ab...@pivotal.io> wrote:
> 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 <kl...@apache.org> wrote:
> >
> > 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 <ji...@pivotal.io> 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 <prhomberg@pivotal.io
> >
> >> wrote:
> >>
> >>> Some types / fields have their deprecation noted in their
> documentation,
> >>> within the <xsd:documentation> block. Alternatively / in addition,
> some
> >>> xsd:element have the block
> >>>
> >>> <xsd:annotation>
> >>> <xsd:appinfo>deprecated</xsd:appinfo>
> >>> </xsd:annotation>
> >>>
> >>>
> >>> 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 <ji...@pivotal.io>
> 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 <jh...@pivotal.io>
> >> 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:
> >>>>>
> >>>>> <index name="pk1">
> >>>>> <primary-key field="ID"/>
> >>>>> </index>
> >>>>>
> >>>>> I believe the "new" way to do this would be:
> >>>>>
> >>>>> <index name="pk1" type="key" from-clause="/region r"
> >> 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 <ji...@pivotal.io>
> >>> 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?
> >>>>>>
> >>>>>> <xsd:choice minOccurs="0">
> >>>>>> <xsd:element name="functional">
> >>>>>> <xsd:annotation>
> >>>>>> <xsd:documentation>
> >>>>>> 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.
> >>>>>> </xsd:documentation>
> >>>>>> </xsd:annotation>
> >>>>>> <xsd:complexType>
> >>>>>> <xsd:attribute name="expression" type="xsd:string"
> >>> use="required"
> >>>>> />
> >>>>>> <xsd:attribute name="from-clause" type="xsd:string"
> >>>> use="required"
> >>>>> />
> >>>>>> <xsd:attribute name="imports" type="xsd:string"
> >> use="optional"
> >>> />
> >>>>>> </xsd:complexType>
> >>>>>> </xsd:element>
> >>>>>>
> >>>>>> <xsd:element name="primary-key">
> >>>>>> <xsd:annotation>
> >>>>>> <xsd:documentation>
> >>>>>> 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
> >>>>>> </xsd:documentation>
> >>>>>> </xsd:annotation>
> >>>>>> <xsd:complexType>
> >>>>>> <xsd:attribute name="field" type="xsd:string" use="required"
> >> />
> >>>>>> </xsd:complexType>
> >>>>>> </xsd:element>
> >>>>>> </xsd:choice>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Cheers
> >>>>>>
> >>>>>> Jinmei
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Cheers
> >>>>
> >>>> Jinmei
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> Cheers
> >>
> >> Jinmei
> >>
>
>
Re: Index on Region
Posted by Anthony Baker <ab...@pivotal.io>.
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 <kl...@apache.org> wrote:
>
> 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 <ji...@pivotal.io> 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 <pr...@pivotal.io>
>> wrote:
>>
>>> Some types / fields have their deprecation noted in their documentation,
>>> within the <xsd:documentation> block. Alternatively / in addition, some
>>> xsd:element have the block
>>>
>>> <xsd:annotation>
>>> <xsd:appinfo>deprecated</xsd:appinfo>
>>> </xsd:annotation>
>>>
>>>
>>> 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 <ji...@pivotal.io> 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 <jh...@pivotal.io>
>> 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:
>>>>>
>>>>> <index name="pk1">
>>>>> <primary-key field="ID"/>
>>>>> </index>
>>>>>
>>>>> I believe the "new" way to do this would be:
>>>>>
>>>>> <index name="pk1" type="key" from-clause="/region r"
>> 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 <ji...@pivotal.io>
>>> 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?
>>>>>>
>>>>>> <xsd:choice minOccurs="0">
>>>>>> <xsd:element name="functional">
>>>>>> <xsd:annotation>
>>>>>> <xsd:documentation>
>>>>>> 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.
>>>>>> </xsd:documentation>
>>>>>> </xsd:annotation>
>>>>>> <xsd:complexType>
>>>>>> <xsd:attribute name="expression" type="xsd:string"
>>> use="required"
>>>>> />
>>>>>> <xsd:attribute name="from-clause" type="xsd:string"
>>>> use="required"
>>>>> />
>>>>>> <xsd:attribute name="imports" type="xsd:string"
>> use="optional"
>>> />
>>>>>> </xsd:complexType>
>>>>>> </xsd:element>
>>>>>>
>>>>>> <xsd:element name="primary-key">
>>>>>> <xsd:annotation>
>>>>>> <xsd:documentation>
>>>>>> 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
>>>>>> </xsd:documentation>
>>>>>> </xsd:annotation>
>>>>>> <xsd:complexType>
>>>>>> <xsd:attribute name="field" type="xsd:string" use="required"
>> />
>>>>>> </xsd:complexType>
>>>>>> </xsd:element>
>>>>>> </xsd:choice>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers
>>>>>>
>>>>>> Jinmei
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers
>>>>
>>>> Jinmei
>>>>
>>>
>>
>>
>>
>> --
>> Cheers
>>
>> Jinmei
>>
Re: Index on Region
Posted by Kirk Lund <kl...@apache.org>.
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 <ji...@pivotal.io> 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 <pr...@pivotal.io>
> wrote:
>
> > Some types / fields have their deprecation noted in their documentation,
> > within the <xsd:documentation> block. Alternatively / in addition, some
> > xsd:element have the block
> >
> > <xsd:annotation>
> > <xsd:appinfo>deprecated</xsd:appinfo>
> > </xsd:annotation>
> >
> >
> > 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 <ji...@pivotal.io> 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 <jh...@pivotal.io>
> 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:
> > > >
> > > > <index name="pk1">
> > > > <primary-key field="ID"/>
> > > > </index>
> > > >
> > > > I believe the "new" way to do this would be:
> > > >
> > > > <index name="pk1" type="key" from-clause="/region r"
> 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 <ji...@pivotal.io>
> > 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?
> > > > >
> > > > > <xsd:choice minOccurs="0">
> > > > > <xsd:element name="functional">
> > > > > <xsd:annotation>
> > > > > <xsd:documentation>
> > > > > 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.
> > > > > </xsd:documentation>
> > > > > </xsd:annotation>
> > > > > <xsd:complexType>
> > > > > <xsd:attribute name="expression" type="xsd:string"
> > use="required"
> > > > />
> > > > > <xsd:attribute name="from-clause" type="xsd:string"
> > > use="required"
> > > > />
> > > > > <xsd:attribute name="imports" type="xsd:string"
> use="optional"
> > />
> > > > > </xsd:complexType>
> > > > > </xsd:element>
> > > > >
> > > > > <xsd:element name="primary-key">
> > > > > <xsd:annotation>
> > > > > <xsd:documentation>
> > > > > 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
> > > > > </xsd:documentation>
> > > > > </xsd:annotation>
> > > > > <xsd:complexType>
> > > > > <xsd:attribute name="field" type="xsd:string" use="required"
> />
> > > > > </xsd:complexType>
> > > > > </xsd:element>
> > > > > </xsd:choice>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers
> > > > >
> > > > > Jinmei
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>
>
>
> --
> Cheers
>
> Jinmei
>
Re: Index on Region
Posted by Jinmei Liao <ji...@pivotal.io>.
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 <pr...@pivotal.io>
wrote:
> Some types / fields have their deprecation noted in their documentation,
> within the <xsd:documentation> block. Alternatively / in addition, some
> xsd:element have the block
>
> <xsd:annotation>
> <xsd:appinfo>deprecated</xsd:appinfo>
> </xsd:annotation>
>
>
> 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 <ji...@pivotal.io> 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 <jh...@pivotal.io> 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:
> > >
> > > <index name="pk1">
> > > <primary-key field="ID"/>
> > > </index>
> > >
> > > I believe the "new" way to do this would be:
> > >
> > > <index name="pk1" type="key" from-clause="/region r" 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 <ji...@pivotal.io>
> 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?
> > > >
> > > > <xsd:choice minOccurs="0">
> > > > <xsd:element name="functional">
> > > > <xsd:annotation>
> > > > <xsd:documentation>
> > > > 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.
> > > > </xsd:documentation>
> > > > </xsd:annotation>
> > > > <xsd:complexType>
> > > > <xsd:attribute name="expression" type="xsd:string"
> use="required"
> > > />
> > > > <xsd:attribute name="from-clause" type="xsd:string"
> > use="required"
> > > />
> > > > <xsd:attribute name="imports" type="xsd:string" use="optional"
> />
> > > > </xsd:complexType>
> > > > </xsd:element>
> > > >
> > > > <xsd:element name="primary-key">
> > > > <xsd:annotation>
> > > > <xsd:documentation>
> > > > 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
> > > > </xsd:documentation>
> > > > </xsd:annotation>
> > > > <xsd:complexType>
> > > > <xsd:attribute name="field" type="xsd:string" use="required" />
> > > > </xsd:complexType>
> > > > </xsd:element>
> > > > </xsd:choice>
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers
> > > >
> > > > Jinmei
> > > >
> > >
> >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
--
Cheers
Jinmei
Re: Index on Region
Posted by Patrick Rhomberg <pr...@pivotal.io>.
Some types / fields have their deprecation noted in their documentation,
within the <xsd:documentation> block. Alternatively / in addition, some
xsd:element have the block
<xsd:annotation>
<xsd:appinfo>deprecated</xsd:appinfo>
</xsd:annotation>
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 <ji...@pivotal.io> 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 <jh...@pivotal.io> 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:
> >
> > <index name="pk1">
> > <primary-key field="ID"/>
> > </index>
> >
> > I believe the "new" way to do this would be:
> >
> > <index name="pk1" type="key" from-clause="/region r" 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 <ji...@pivotal.io> 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?
> > >
> > > <xsd:choice minOccurs="0">
> > > <xsd:element name="functional">
> > > <xsd:annotation>
> > > <xsd:documentation>
> > > 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.
> > > </xsd:documentation>
> > > </xsd:annotation>
> > > <xsd:complexType>
> > > <xsd:attribute name="expression" type="xsd:string" use="required"
> > />
> > > <xsd:attribute name="from-clause" type="xsd:string"
> use="required"
> > />
> > > <xsd:attribute name="imports" type="xsd:string" use="optional" />
> > > </xsd:complexType>
> > > </xsd:element>
> > >
> > > <xsd:element name="primary-key">
> > > <xsd:annotation>
> > > <xsd:documentation>
> > > 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
> > > </xsd:documentation>
> > > </xsd:annotation>
> > > <xsd:complexType>
> > > <xsd:attribute name="field" type="xsd:string" use="required" />
> > > </xsd:complexType>
> > > </xsd:element>
> > > </xsd:choice>
> > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>
>
>
> --
> Cheers
>
> Jinmei
>
Re: Index on Region
Posted by Jinmei Liao <ji...@pivotal.io>.
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 <jh...@pivotal.io> 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:
>
> <index name="pk1">
> <primary-key field="ID"/>
> </index>
>
> I believe the "new" way to do this would be:
>
> <index name="pk1" type="key" from-clause="/region r" 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 <ji...@pivotal.io> 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?
> >
> > <xsd:choice minOccurs="0">
> > <xsd:element name="functional">
> > <xsd:annotation>
> > <xsd:documentation>
> > 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.
> > </xsd:documentation>
> > </xsd:annotation>
> > <xsd:complexType>
> > <xsd:attribute name="expression" type="xsd:string" use="required"
> />
> > <xsd:attribute name="from-clause" type="xsd:string" use="required"
> />
> > <xsd:attribute name="imports" type="xsd:string" use="optional" />
> > </xsd:complexType>
> > </xsd:element>
> >
> > <xsd:element name="primary-key">
> > <xsd:annotation>
> > <xsd:documentation>
> > 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
> > </xsd:documentation>
> > </xsd:annotation>
> > <xsd:complexType>
> > <xsd:attribute name="field" type="xsd:string" use="required" />
> > </xsd:complexType>
> > </xsd:element>
> > </xsd:choice>
> >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
--
Cheers
Jinmei
Re: Index on Region
Posted by Jason Huynh <jh...@pivotal.io>.
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:
<index name="pk1">
<primary-key field="ID"/>
</index>
I believe the "new" way to do this would be:
<index name="pk1" type="key" from-clause="/region r" 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 <ji...@pivotal.io> 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?
>
> <xsd:choice minOccurs="0">
> <xsd:element name="functional">
> <xsd:annotation>
> <xsd:documentation>
> 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.
> </xsd:documentation>
> </xsd:annotation>
> <xsd:complexType>
> <xsd:attribute name="expression" type="xsd:string" use="required" />
> <xsd:attribute name="from-clause" type="xsd:string" use="required" />
> <xsd:attribute name="imports" type="xsd:string" use="optional" />
> </xsd:complexType>
> </xsd:element>
>
> <xsd:element name="primary-key">
> <xsd:annotation>
> <xsd:documentation>
> 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
> </xsd:documentation>
> </xsd:annotation>
> <xsd:complexType>
> <xsd:attribute name="field" type="xsd:string" use="required" />
> </xsd:complexType>
> </xsd:element>
> </xsd:choice>
>
>
>
> --
> Cheers
>
> Jinmei
>