[JBoss JIRA] (ISPN-7842) Declarative indexed entity mapping
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-7842?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-7842:
-------------------------------------
Putting domain related data or metadata in a server config xml is going to upset many developers. Having to list the class names that need to be indexed is mildly bad, I accepted it when we agreed to introduce it, especially because entity autodetection was kind enough to let you develop your domain model and then put the whole list of types there when you were done with it. But exposing the inner structure of your domain model adds a new dimension to the problem; makes me want to reconsider. Especially since we have a completely different mechanism to handle this for protobuf entities.
> Declarative indexed entity mapping
> ----------------------------------
>
> Key: ISPN-7842
> URL: https://issues.jboss.org/browse/ISPN-7842
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Embedded Querying
> Reporter: Tristan Tarrant
> Assignee: Jakub Senko
> Priority: Minor
>
> We need a way to list annotation-less indexed entities in the infinispan XML.
> The
> {noformat}
> <indexed-entities>
> {noformat}
> element schema will need to be extended as follows:
> {code:xml}
> <indexed-entities>
> <!-- annotated entity -->
> <indexed-entity>org.infinispan.query.queries.faceting.Car</indexed-entity>
> <!-- non-annotated entity -->
> <indexed-entity-mapping>
> <!-- the FQN of the class to index -->
> <class>my.domain.model.Author</class>
> <!-- optional -->
> <spatial name="place" mode="HASH"/>
> <!-- list of indexed properties -->
> <property name="name" type="method">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5"/>
> </property>
> <property name="title" type="method">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5" analyzer="titleanalyzer"/>
> </property>
> <property type="method" name="birthdate">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5"/>
> <date-bridge resolution="DAY"/>
> </property>
>
> <property type="method" name="city">
> <spatial name="name" store="true" boost="0.5" spatial-mode="RANGE" />
> </property>
> </indexed-entity-mapping>
> </indexed-entities>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-7842) Declarative indexed entity mapping
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-7842?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-7842:
-------------------------------------
Current state: implementation of <indexed-entities> is just a list of type names, which are currently just classes, no protobuf types (yet). This works in embedded mode only. In server mode it has little chance of working due to various deployment dependencies issues; so this xml element is present in server's xsd but is ignored as of 9.0.0.final.
> Declarative indexed entity mapping
> ----------------------------------
>
> Key: ISPN-7842
> URL: https://issues.jboss.org/browse/ISPN-7842
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Embedded Querying
> Reporter: Tristan Tarrant
> Assignee: Jakub Senko
> Priority: Minor
>
> We need a way to list annotation-less indexed entities in the infinispan XML.
> The
> {noformat}
> <indexed-entities>
> {noformat}
> element schema will need to be extended as follows:
> {code:xml}
> <indexed-entities>
> <!-- annotated entity -->
> <indexed-entity>org.infinispan.query.queries.faceting.Car</indexed-entity>
> <!-- non-annotated entity -->
> <indexed-entity-mapping>
> <!-- the FQN of the class to index -->
> <class>my.domain.model.Author</class>
> <!-- optional -->
> <spatial name="place" mode="HASH"/>
> <!-- list of indexed properties -->
> <property name="name" type="method">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5"/>
> </property>
> <property name="title" type="method">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5" analyzer="titleanalyzer"/>
> </property>
> <property type="method" name="birthdate">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5"/>
> <date-bridge resolution="DAY"/>
> </property>
>
> <property type="method" name="city">
> <spatial name="name" store="true" boost="0.5" spatial-mode="RANGE" />
> </property>
> </indexed-entity-mapping>
> </indexed-entities>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-7842) Declarative indexed entity mapping
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7842?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes edited comment on ISPN-7842 at 5/16/17 6:15 AM:
------------------------------------------------------------------
What if my POJO is not a POJO, but a protobuf entity? It'd nice, as a non-java client, to be able to define my mapping in a declarative XML way. This means keeping the schema generic enough to support both embedded and client/server cases.
was (Author: gustavonalle):
What if my POJO is not a POJO, but a protobuf entity? It'd nice, as a non-java client, to be able to define my mapping programmatically. This means keeping the schema generic enough to support both embedded and client/server cases.
> Declarative indexed entity mapping
> ----------------------------------
>
> Key: ISPN-7842
> URL: https://issues.jboss.org/browse/ISPN-7842
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Embedded Querying
> Reporter: Tristan Tarrant
> Assignee: Jakub Senko
> Priority: Minor
>
> We need a way to list annotation-less indexed entities in the infinispan XML.
> The
> {noformat}
> <indexed-entities>
> {noformat}
> element schema will need to be extended as follows:
> {code:xml}
> <indexed-entities>
> <!-- annotated entity -->
> <indexed-entity>org.infinispan.query.queries.faceting.Car</indexed-entity>
> <!-- non-annotated entity -->
> <indexed-entity-mapping>
> <!-- the FQN of the class to index -->
> <class>my.domain.model.Author</class>
> <!-- optional -->
> <spatial name="place" mode="HASH"/>
> <!-- list of indexed properties -->
> <property name="name" type="method">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5"/>
> </property>
> <property name="title" type="method">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5" analyzer="titleanalyzer"/>
> </property>
> <property type="method" name="birthdate">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5"/>
> <date-bridge resolution="DAY"/>
> </property>
>
> <property type="method" name="city">
> <spatial name="name" store="true" boost="0.5" spatial-mode="RANGE" />
> </property>
> </indexed-entity-mapping>
> </indexed-entities>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-7842) Declarative indexed entity mapping
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7842?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-7842:
-----------------------------------------
What if my POJO is not a POJO, but a protobuf entity? It'd nice, as a non-java client, to be able to define my mapping programmatically. This means keeping the schema generic enough to support both embedded and client/server cases.
> Declarative indexed entity mapping
> ----------------------------------
>
> Key: ISPN-7842
> URL: https://issues.jboss.org/browse/ISPN-7842
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Embedded Querying
> Reporter: Tristan Tarrant
> Assignee: Jakub Senko
> Priority: Minor
>
> We need a way to list annotation-less indexed entities in the infinispan XML.
> The
> {noformat}
> <indexed-entities>
> {noformat}
> element schema will need to be extended as follows:
> {code:xml}
> <indexed-entities>
> <!-- annotated entity -->
> <indexed-entity>org.infinispan.query.queries.faceting.Car</indexed-entity>
> <!-- non-annotated entity -->
> <indexed-entity-mapping>
> <!-- the FQN of the class to index -->
> <class>my.domain.model.Author</class>
> <!-- optional -->
> <spatial name="place" mode="HASH"/>
> <!-- list of indexed properties -->
> <property name="name" type="method">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5"/>
> </property>
> <property name="title" type="method">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5" analyzer="titleanalyzer"/>
> </property>
> <property type="method" name="birthdate">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5"/>
> <date-bridge resolution="DAY"/>
> </property>
>
> <property type="method" name="city">
> <spatial name="name" store="true" boost="0.5" spatial-mode="RANGE" />
> </property>
> </indexed-entity-mapping>
> </indexed-entities>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-7842) Declarative indexed entity mapping
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-7842?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero edited comment on ISPN-7842 at 5/16/17 6:05 AM:
----------------------------------------------------------------
h5. High level questions
# (?) I assume the intent that - for a given class type {{A}} - it's going to be mapped *either* via annotations *or* via explicit mapping? (I would suggest to expect that, at least for the first iterations, as we don't support integrating the two at the moment)
# (/) (follow up on previous question) I hope you'll enforce (validate) against listing the same class in both ways
# (flag) We will need to require the actual class definition to be "on classpath" during bootstrap of the Cache. I hope that's fine for the use case?
h5. Property mapping
# (-) Let's not expose index-time boost. We'll deprecate / remove this soon.
# (?) I'm confused about the Spatial mapping example on _city_. Could you add the entity sources to clarify? i.e. you'll need matching {{@Latitude}} and {{@Longitude}} for each Spatial coordinates-set, unless these are embeddables but then you'll need nested mapping.
# (i) _norms_, _term-vectors_, etc.. : in the annotations case we use enums. Let's implement the XML schema to match, i.e. don't accept any string.
# Being able to support {{@FieldBridge}} is typically quite important.
h5. Entity Properties vs Entity Fields
Hibernate Search can map either properties and/or fields. We can read/write to Java fields, and this is supported by Infinispan Query as well.
When having
{code:xml}
<property name="name" type="method">
<field ...
{code}
I guess _type_ refers to a getter? A "method" should typically match the full method name. Yet a "getter" is slang for *property* so the block already hinted about it.
Should {{<property>}} be named differently, and have two different identifiers to get rid of the _type_ ?
Should the inner _field_ be named _documentField_ or _indexField_ ?
The {{@Field}} annotation is not ambiguous as one can see it's not a POJO field, but in this context it reads ambiguously.
h5. Nested structures?
What if my POJO contains a map/set of many (one/none/null) objects which need to be mapped ?
In Hibernate Search we support the recursion into the related types, but the child element doesn't have to be {{@Indexed}} on its own.
(!) Careful with polymorphic collections.
h5. Analyzer definitions?
I don't think we need to expose all of Hibernate Search features, but defining Analyzers is essential.
h5. Mapping / converstion of Infinispan *keys*
The concept of a separate key is not native in Hibernate Search, yet you need a way to define how key types being used are two-way converted to the index format. This is represented as a {{@ProvidedId}} in the Hibernate Search _internals_ but in this case you might want to expose them in a simpler form.
was (Author: sannegrinovero):
h5. High level questions
# (?) I assume the intent that - for a given class type {{A}} - it's going to be mapped *either* via annotations *or* via explicit mapping? (I would suggest to expect that, at least for the first iterations, as we don't support integrating the two at the moment)
# (/) (follow up on previous question) I hope you'll enforce (validate) against listing the same class in both ways
# (flag) We will need to require the actual class definition to be "on classpath" during bootstrap of the Cache. I hope that's fine for the use case?
h5. Property mapping
# (-) Let's not expose index-time boost. We'll deprecate / remove this soon.
# (?) I'm confused about the Spatial mapping example on _city_. Could you add the entity sources to clarify? i.e. you'll need matching {{@Latitude}} and {{@Longitude}} for each Spatial coordinates-set, unless these are embeddables but then you'll need nested mapping.
# (i) _norms_, _term-vectors_, etc.. : in the annotations case we use enums. Let's implement the XML schema to match, i.e. don't accept any string.
# Being able to support {{@FieldBridge}} is typically quite important.
h5. Entity Properties vs Entity Fields
Hibernate Search can map either properties and/or fields. We can read/write to Java fields, and this is supported by Infinispan Query as well.
When having
{code:xml}
<property name="name" type="method">
<field ...
{code}
I guess _type_refers to a getter? A "method" should typically match the full method name. Yet a "getter" is slang for *property* so the block already hinted about it.
Should {{<property>}} be named differently, and have two different identifiers to get rid of the _type_ ?
Should the inner _field_ be named _documentField_ or _indexField_ ?
The {{@Field}} annotation is not ambiguous as one can see it's not a POJO field, but in this context it reads ambiguously.
h5. Nested structures?
What if my POJO contains a map/set of many (one/none/null) objects which need to be mapped ?
In Hibernate Search we support the recursion into the related types, but the child element doesn't have to be {{@Indexed}} on its own.
(!) Careful with polymorphic collections
h5. Analyzer definitions?
I don't think we need to expose all of Hibernate Search features, but defining Analyzers is essential.
h5. Mapping / converstion of Infinispan *keys*
The concept of a separate key is not native in Hibernate Search, yet you need a way to define how key types being used are two-way converted to the index format. This is represented as a {{@ProvidedId}} in the Hibernate Search _internals_ but in this case you might want to expose them in a simpler form.
> Declarative indexed entity mapping
> ----------------------------------
>
> Key: ISPN-7842
> URL: https://issues.jboss.org/browse/ISPN-7842
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Embedded Querying
> Reporter: Tristan Tarrant
> Assignee: Jakub Senko
> Priority: Minor
>
> We need a way to list annotation-less indexed entities in the infinispan XML.
> The
> {noformat}
> <indexed-entities>
> {noformat}
> element schema will need to be extended as follows:
> {code:xml}
> <indexed-entities>
> <!-- annotated entity -->
> <indexed-entity>org.infinispan.query.queries.faceting.Car</indexed-entity>
> <!-- non-annotated entity -->
> <indexed-entity-mapping>
> <!-- the FQN of the class to index -->
> <class>my.domain.model.Author</class>
> <!-- optional -->
> <spatial name="place" mode="HASH"/>
> <!-- list of indexed properties -->
> <property name="name" type="method">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5"/>
> </property>
> <property name="title" type="method">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5" analyzer="titleanalyzer"/>
> </property>
> <property type="method" name="birthdate">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5"/>
> <date-bridge resolution="DAY"/>
> </property>
>
> <property type="method" name="city">
> <spatial name="name" store="true" boost="0.5" spatial-mode="RANGE" />
> </property>
> </indexed-entity-mapping>
> </indexed-entities>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-7842) Declarative indexed entity mapping
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-7842?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero edited comment on ISPN-7842 at 5/16/17 6:01 AM:
----------------------------------------------------------------
h5. High level questions
# (?) I assume the intent that - for a given class type {{A}} - it's going to be mapped *either* via annotations *or* via explicit mapping? (I would suggest to expect that, at least for the first iterations, as we don't support integrating the two at the moment)
# (/) (follow up on previous question) I hope you'll enforce (validate) against listing the same class in both ways
# (flag) We will need to require the actual class definition to be "on classpath" during bootstrap of the Cache. I hope that's fine for the use case?
h5. Property mapping
# (-) Let's not expose index-time boost. We'll deprecate / remove this soon.
# (?) I'm confused about the Spatial mapping example on _city_. Could you add the entity sources to clarify? i.e. you'll need matching {{@Latitude}} and {{@Longitude}} for each Spatial coordinates-set, unless these are embeddables but then you'll need nested mapping.
# (i) _norms_, _term-vectors_, etc.. : in the annotations case we use enums. Let's implement the XML schema to match, i.e. don't accept any string.
# Being able to support {{@FieldBridge}} is typically quite important.
h5. Entity Properties vs Entity Fields
Hibernate Search can map either properties and/or fields. We can read/write to Java fields, and this is supported by Infinispan Query as well.
When having
{code:xml}
<property name="name" type="method">
<field ...
{code}
I guess _type_refers to a getter? A "method" should typically match the full method name. Yet a "getter" is slang for *property* so the block already hinted about it.
Should {{<property>}} be named differently, and have two different identifiers to get rid of the _type_ ?
Should the inner _field_ be named _documentField_ or _indexField_ ?
The {{@Field}} annotation is not ambiguous as one can see it's not a POJO field, but in this context it reads ambiguously.
h5. Nested structures?
What if my POJO contains a map/set of many (one/none/null) objects which need to be mapped ?
In Hibernate Search we support the recursion into the related types, but the child element doesn't have to be {{@Indexed}} on its own.
(!) Careful with polymorphic collections
h5. Analyzer definitions?
I don't think we need to expose all of Hibernate Search features, but defining Analyzers is essential.
h5. Mapping / converstion of Infinispan *keys*
The concept of a separate key is not native in Hibernate Search, yet you need a way to define how key types being used are two-way converted to the index format. This is represented as a {{@ProvidedId}} in the Hibernate Search _internals_ but in this case you might want to expose them in a simpler form.
was (Author: sannegrinovero):
h5. High level questions
# (?) I assume the intent that - for a given class type {{A}} - it's going to be mapped *either* via annotations *or* via explicit mapping? (I would suggest to expect that, at least for the first iterations, as we don't support integrating the two at the moment)
# (/) (follow up on previous question) I hope you'll enforce (validate) against listing the same class in both ways
# (flag) We will need to require the actual class definition to be "on classpath" during bootstrap of the Cache. I hope that's fine for the use case?
h5. Property mapping
# (-) Let's not expose index-time boost. We'll deprecate / remove this soon.
# (?) I'm confused about the Spatial mapping example on _city_. Could you add the entity sources to clarify? i.e. you'll need matching {{@Latitude}} and {{@Longitude}} for each Spatial coordinates-set, unless these are embeddables but then you'll need nested mapping.
# (i) _norms_, _term-vectors_, etc.. : in the annotations case we use enums. Let's implement the XML schema to match, i.e. don't accept any string.
# Being able to support {{@FieldBridge}} is typically quite important.
h5. Entity Properties vs Entity Fields
Hibernate Search can map either properties and/or fields. We can read/write to Java fields, and this is supported by Infinispan Query as well.
When having
{code:xml}
<property name="name" type="method">
<field ...
{code}
I guess _type_refers to a getter? A "method" should typically match the full method name. Yet a "getter" is slang for *property* so the block already hinted about it.
Should {{<property>}} be named differently, and have two different identifiers to get rid of the _type_ ?
Should the inner _field_ be named _documentField_ or _indexField_ ?
The {{@Field}} annotation is not ambiguous as one can see it's not a POJO field, but in this context it reads ambiguously.
h5. Nested structures?
What if my POJO contains a map/set of many (one/none/null) objects which need to be mapped ?
In Hibernate Search we support the recursion into the related types, but the child element doesn't have to be {{@Indexed}} on its own.
(!) Careful with polymorphic collections
h5. Analyzer definitions?
I don't think we need to expose all of Hibernate Search features, but defining Analyzers is essential.
> Declarative indexed entity mapping
> ----------------------------------
>
> Key: ISPN-7842
> URL: https://issues.jboss.org/browse/ISPN-7842
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Embedded Querying
> Reporter: Tristan Tarrant
> Assignee: Jakub Senko
> Priority: Minor
>
> We need a way to list annotation-less indexed entities in the infinispan XML.
> The
> {noformat}
> <indexed-entities>
> {noformat}
> element schema will need to be extended as follows:
> {code:xml}
> <indexed-entities>
> <!-- annotated entity -->
> <indexed-entity>org.infinispan.query.queries.faceting.Car</indexed-entity>
> <!-- non-annotated entity -->
> <indexed-entity-mapping>
> <!-- the FQN of the class to index -->
> <class>my.domain.model.Author</class>
> <!-- optional -->
> <spatial name="place" mode="HASH"/>
> <!-- list of indexed properties -->
> <property name="name" type="method">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5"/>
> </property>
> <property name="title" type="method">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5" analyzer="titleanalyzer"/>
> </property>
> <property type="method" name="birthdate">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5"/>
> <date-bridge resolution="DAY"/>
> </property>
>
> <property type="method" name="city">
> <spatial name="name" store="true" boost="0.5" spatial-mode="RANGE" />
> </property>
> </indexed-entity-mapping>
> </indexed-entities>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-7842) Declarative indexed entity mapping
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-7842?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero edited comment on ISPN-7842 at 5/16/17 5:58 AM:
----------------------------------------------------------------
h5. High level questions
# (?) I assume the intent that - for a given class type {{A}} - it's going to be mapped *either* via annotations *or* via explicit mapping? (I would suggest to expect that, at least for the first iterations, as we don't support integrating the two at the moment)
# (/) (follow up on previous question) I hope you'll enforce (validate) against listing the same class in both ways
# (flag) We will need to require the actual class definition to be "on classpath" during bootstrap of the Cache. I hope that's fine for the use case?
h5. Property mapping
# (-) Let's not expose index-time boost. We'll deprecate / remove this soon.
# (?) I'm confused about the Spatial mapping example on _city_. Could you add the entity sources to clarify? i.e. you'll need matching {{@Latitude}} and {{@Longitude}} for each Spatial coordinates-set, unless these are embeddables but then you'll need nested mapping.
# (i) _norms_, _term-vectors_, etc.. : in the annotations case we use enums. Let's implement the XML schema to match, i.e. don't accept any string.
# Being able to support {{@FieldBridge}} is typically quite important.
h5. Entity Properties vs Entity Fields
Hibernate Search can map either properties and/or fields. We can read/write to Java fields, and this is supported by Infinispan Query as well.
When having
{code:xml}
<property name="name" type="method">
<field ...
{code}
I guess _type_refers to a getter? A "method" should typically match the full method name. Yet a "getter" is slang for *property* so the block already hinted about it.
Should {{<property>}} be named differently, and have two different identifiers to get rid of the _type_ ?
Should the inner _field_ be named _documentField_ or _indexField_ ?
The {{@Field}} annotation is not ambiguous as one can see it's not a POJO field, but in this context it reads ambiguously.
h5. Nested structures?
What if my POJO contains a map/set of many (one/none/null) objects which need to be mapped ?
In Hibernate Search we support the recursion into the related types, but the child element doesn't have to be {{@Indexed}} on its own.
(!) Careful with polymorphic collections
h5. Analyzer definitions?
I don't think we need to expose all of Hibernate Search features, but defining Analyzers is essential.
was (Author: sannegrinovero):
h5. High level questions
# (?) I assume the intent that - for a given class type {{A}} - it's going to be mapped *either* via annotations *or* via explicit mapping? (I would suggest to expect that, at least for the first iterations, as we don't support integrating the two at the moment)
# (/) (follow up on previous question) I hope you'll enforce (validate) against listing the same class in both ways
# (flag) We will need to require the actual class definition to be "on classpath" during bootstrap of the Cache. I hope that's fine for the use case?
> Declarative indexed entity mapping
> ----------------------------------
>
> Key: ISPN-7842
> URL: https://issues.jboss.org/browse/ISPN-7842
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Embedded Querying
> Reporter: Tristan Tarrant
> Assignee: Jakub Senko
> Priority: Minor
>
> We need a way to list annotation-less indexed entities in the infinispan XML.
> The
> {noformat}
> <indexed-entities>
> {noformat}
> element schema will need to be extended as follows:
> {code:xml}
> <indexed-entities>
> <!-- annotated entity -->
> <indexed-entity>org.infinispan.query.queries.faceting.Car</indexed-entity>
> <!-- non-annotated entity -->
> <indexed-entity-mapping>
> <!-- the FQN of the class to index -->
> <class>my.domain.model.Author</class>
> <!-- optional -->
> <spatial name="place" mode="HASH"/>
> <!-- list of indexed properties -->
> <property name="name" type="method">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5"/>
> </property>
> <property name="title" type="method">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5" analyzer="titleanalyzer"/>
> </property>
> <property type="method" name="birthdate">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5"/>
> <date-bridge resolution="DAY"/>
> </property>
>
> <property type="method" name="city">
> <spatial name="name" store="true" boost="0.5" spatial-mode="RANGE" />
> </property>
> </indexed-entity-mapping>
> </indexed-entities>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-7842) Declarative indexed entity mapping
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7842?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-7842:
-----------------------------------------
We'd also need a section for the *Analyzers*, which are not necessarily tied to a certain entity, but can be referenced by name
> Declarative indexed entity mapping
> ----------------------------------
>
> Key: ISPN-7842
> URL: https://issues.jboss.org/browse/ISPN-7842
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Embedded Querying
> Reporter: Tristan Tarrant
> Assignee: Jakub Senko
> Priority: Minor
>
> We need a way to list annotation-less indexed entities in the infinispan XML.
> The
> {noformat}
> <indexed-entities>
> {noformat}
> element schema will need to be extended as follows:
> {code:xml}
> <indexed-entities>
> <!-- annotated entity -->
> <indexed-entity>org.infinispan.query.queries.faceting.Car</indexed-entity>
> <!-- non-annotated entity -->
> <indexed-entity-mapping>
> <!-- the FQN of the class to index -->
> <class>my.domain.model.Author</class>
> <!-- optional -->
> <spatial name="place" mode="HASH"/>
> <!-- list of indexed properties -->
> <property name="name" type="method">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5"/>
> </property>
> <property name="title" type="method">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5" analyzer="titleanalyzer"/>
> </property>
> <property type="method" name="birthdate">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5"/>
> <date-bridge resolution="DAY"/>
> </property>
>
> <property type="method" name="city">
> <spatial name="name" store="true" boost="0.5" spatial-mode="RANGE" />
> </property>
> </indexed-entity-mapping>
> </indexed-entities>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-7842) Declarative indexed entity mapping
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-7842?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero edited comment on ISPN-7842 at 5/16/17 5:34 AM:
----------------------------------------------------------------
h5. High level questions
# (?) I assume the intent that - for a given class type {{A}} - it's going to be mapped *either* via annotations *or* via explicit mapping? (I would suggest to expect that, at least for the first iterations, as we don't support integrating the two at the moment)
# (/) (follow up on previous question) I hope you'll enforce (validate) against listing the same class in both ways
# (flag) We will need to require the actual class definition to be "on classpath" during bootstrap of the Cache. I hope that's fine for the use case?
was (Author: sannegrinovero):
h5. High level questions
## (?) I assume the intent that - for a given class type {{A}} - it's going to be mapped *either* via annotations *or* via explicit mapping? (I would suggest to expect that, at least for the first iterations, as we don't support integrating the two at the moment)
## (/) (follow up on previous question) I hope you'll enforce (validate) against listing the same class in both ways
## (flag) We will need to require the actual class definition to be "on classpath" during bootstrap of the Cache. I hope that's fine for the use case?
> Declarative indexed entity mapping
> ----------------------------------
>
> Key: ISPN-7842
> URL: https://issues.jboss.org/browse/ISPN-7842
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Embedded Querying
> Reporter: Tristan Tarrant
> Assignee: Jakub Senko
> Priority: Minor
>
> We need a way to list annotation-less indexed entities in the infinispan XML.
> The
> {noformat}
> <indexed-entities>
> {noformat}
> element schema will need to be extended as follows:
> {code:xml}
> <indexed-entities>
> <!-- annotated entity -->
> <indexed-entity>org.infinispan.query.queries.faceting.Car</indexed-entity>
> <!-- non-annotated entity -->
> <indexed-entity-mapping>
> <!-- the FQN of the class to index -->
> <class>my.domain.model.Author</class>
> <!-- optional -->
> <spatial name="place" mode="HASH"/>
> <!-- list of indexed properties -->
> <property name="name" type="method">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5"/>
> </property>
> <property name="title" type="method">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5" analyzer="titleanalyzer"/>
> </property>
> <property type="method" name="birthdate">
> <field store="true" index="true" analyze="true" norms="true" term-vector="yes" boost="0.5"/>
> <date-bridge resolution="DAY"/>
> </property>
>
> <property type="method" name="city">
> <spatial name="name" store="true" boost="0.5" spatial-mode="RANGE" />
> </property>
> </indexed-entity-mapping>
> </indexed-entities>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months