subject:"\[jira\] \[Commented\] \(SOLR\-5084\) new field type \- EnumField"

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-11-05 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13814185#comment-13814185
 ] 

ASF subversion and git services commented on SOLR-5084:
---

Commit 1539111 from [~erickoerickson] in branch 'dev/trunk'
[ https://svn.apache.org/r1539111 ]

SOLR-5084: added enum field type to Solr

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
Assignee: Erick Erickson
 Attachments: Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, 
 Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch, enumsConfig.xml, schema_example.xml


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-11-05 Thread Erick Erickson (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13814194#comment-13814194
 ] 

Erick Erickson commented on SOLR-5084:
--

Elran:

I broke out the addition of the enums into the schema.xml used for testing into 
it's own file so we didn't have issues with other tests FWIW.

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
Assignee: Erick Erickson
 Attachments: Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, 
 Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch, enumsConfig.xml, schema_example.xml


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-11-05 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13814243#comment-13814243
 ] 

ASF subversion and git services commented on SOLR-5084:
---

Commit 1539128 from [~erickoerickson] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1539128 ]

SOLR-5084: new enum field type

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
Assignee: Erick Erickson
 Fix For: 4.6, 5.0

 Attachments: Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, 
 Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch, enumsConfig.xml, schema_example.xml


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-11-05 Thread Erick Erickson (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13814245#comment-13814245
 ] 

Erick Erickson commented on SOLR-5084:
--

Thanks Elran!!

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
Assignee: Erick Erickson
 Fix For: 4.6, 5.0

 Attachments: Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, 
 Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch, enumsConfig.xml, schema_example.xml


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-11-05 Thread Elran Dvir (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13814661#comment-13814661
 ] 

Elran Dvir commented on SOLR-5084:
--

Thank you, Erick!

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
Assignee: Erick Erickson
 Fix For: 4.6, 5.0

 Attachments: Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, 
 Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch, enumsConfig.xml, schema_example.xml


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-11-01 Thread Erick Erickson (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13811683#comment-13811683
]

Erick Erickson commented on SOLR-5084:
--

OK, looks good. On my Mac, I get two failures, but I also get those same
failures in trunk without the patch.

So unless someone objects, I'll commit this over the weekend.

new field type - EnumField
--

Key: SOLR-5084
URL: https://issues.apache.org/jira/browse/SOLR-5084
Project: Solr
Issue Type: New Feature
Reporter: Elran Dvir
Assignee: Erick Erickson
Attachments: Solr-5084.patch, Solr-5084.patch, Solr-5084.patch,
Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch,
Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch,
Solr-5084.trunk.patch, Solr-5084.trunk.patch, enumsConfig.xml,
schema_example.xml

We have encountered a use case in our system where we have a few fields
(Severity. Risk etc) with a closed set of values, where the sort order for
these values is pre-determined but not lexicographic (Critical is higher than
High). Generically this is very close to how enums work.
To implement, I have prototyped a new type of field: EnumField where the
inputs are a closed predefined set of strings in a special configuration
file (similar to currency.xml).
The code is based on 4.2.1.

--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-10-31 Thread Elran Dvir (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13810092#comment-13810092
]

Elran Dvir commented on SOLR-5084:
--

Attached new patch
Fixes our test issues. Added putConfig(conf1, zkClient, solrhome,
enumsConfig.xml); in buildZooKeeper in LeaderElectionIntegrationTest.
There are still test errors but I don't think it's related to our patch (thread
leaked from SUITE scope at org.apache.solr.servlet.SolrRequestParserTest).

Thanks.

new field type - EnumField
--

--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-10-30 Thread Elran Dvir (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13809013#comment-13809013
]

Elran Dvir commented on SOLR-5084:
--

Hi Erick,

I have added the necessary JavaDocs. Now 'ant precommit' finishes successfully
I have attached updated patch.
You can ignore the 4.x version. It's only here because it's the version I
started with.

Thank you very much!

new field type - EnumField
--

Key: SOLR-5084
URL: https://issues.apache.org/jira/browse/SOLR-5084
Project: Solr
Issue Type: New Feature
Reporter: Elran Dvir
Assignee: Erick Erickson
Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch,
Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch,
Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch,
Solr-5084.trunk.patch

--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-10-13 Thread Elran Dvir (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793595#comment-13793595
 ] 

Elran Dvir commented on SOLR-5084:
--

Hi all,

Did anyone have a chance to examine the latest patch? Is everthing fine?

Thanks.

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
Assignee: Erick Erickson
 Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, 
 Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch, Solr-5084.trunk.patch


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-10-13 Thread Erick Erickson (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793613#comment-13793613
 ] 

Erick Erickson commented on SOLR-5084:
--

Elran:

I haven't forgotten, I've just been swamped. I'll try to get to it Real Soon 
Now, but I'm traveling for the next 10 days. Anyone who wants to go ahead and 
grab and commit this please feel free!

Erick

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
Assignee: Erick Erickson
 Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, 
 Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch, Solr-5084.trunk.patch


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-10-13 Thread Elran Dvir (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793683#comment-13793683
 ] 

Elran Dvir commented on SOLR-5084:
--

Thanks!

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
Assignee: Erick Erickson
 Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, 
 Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch, Solr-5084.trunk.patch


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-09-18 Thread Erick Erickson (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770970#comment-13770970
]

Erick Erickson commented on SOLR-5084:
--

Rough draft comments. I won't be able to do anything more until this evening
(Pacific time), in meetings all day.

Elran

1 What do you (and others) think about putting the enum right in the
schema.xml file,
perhaps as as many children of fieldsenum/enumenum/enum/fields as
necessary?
That would at least keep them together and not introduce a separate file.

1.5 There's still the IntelliJ headers in the new files, should be removed.

2 JavabinCodec.java
SOLRINPUTDOC_CHILDS = 17,

//Why is this value identical to SOLRINPUTDOC_CHILDS? It may be fine,
verifying
ENUM_FIELD_VALUE = 17,

3 StatsValuesFactory.updateMinMax. How does this.max ever get set to non-null?

4 EnumField.java.
You have a custom field isNullOrEmpty. There's nothing wrong with this,
but StringUtils.isBlank already takes care of this, less code to maintain.

storedToIndexed isn't referenced and, at least in trunk, doesn't show as
being
overridden (haven't checked 4x). May be OK but

5 EnumFieldTest.java
How about a couple of tests that exercise inclusive and exclusive ranges
with defined
endpoints rather than [* TO *]?
The general coding practice (even though I like the leading underscore for
member
vars personally) is to not have them, please change.

new field type - EnumField
--

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-09-18 Thread Ryan Ernst (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13771183#comment-13771183
 ] 

Ryan Ernst commented on SOLR-5084:
--

{quote}
 What do you (and others) think about putting the enum right in the schema.xml 
file,
perhaps as as many children of fieldsenum/enumenum/enum/fields as 
necessary?
That would at least keep them together and not introduce a separate file.
{quote}

Inlining within schema.xml would definitely be better.  But do we need children 
at all?  Why not just an attribute with a comma separated list (and allow for 
comma escaping)?

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
Assignee: Erick Erickson
 Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, 
 Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-09-17 Thread Elran Dvir (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13769270#comment-13769270
 ] 

Elran Dvir commented on SOLR-5084:
--

Thanks!

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
Assignee: Erick Erickson
 Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, 
 Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-09-16 Thread Elran Dvir (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13768442#comment-13768442
 ] 

Elran Dvir commented on SOLR-5084:
--

Hi all,

Did any have a chance to examine the latest patch?

Thanks. 

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
Assignee: Erick Erickson
 Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, 
 Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-09-16 Thread Erick Erickson (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13768661#comment-13768661
 ] 

Erick Erickson commented on SOLR-5084:
--

I have a flight coming up, I'll see if I can give it a look-see.

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
Assignee: Erick Erickson
 Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, 
 Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-09-01 Thread Elran Dvir (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13755744#comment-13755744
 ] 

Elran Dvir commented on SOLR-5084:
--

Hi all,

I attached a new patch that contains:
1.Integer values in enum configuration are now implicit 0-N 
2.Throw exception when indexed value is not in the configuration (either 
numeric or string)

Should I change the example directory to demonstrate the use? If so, how?

Thanks.


 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
Assignee: Erick Erickson
 Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, 
 Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, 
 Solr-5084.trunk.patch


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-31 Thread Erick Erickson (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13755524#comment-13755524
 ] 

Erick Erickson commented on SOLR-5084:
--

Assigned it to myself just so it stays on my radar, Elran is still driving the 
bus

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
Assignee: Erick Erickson
 Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, 
 Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-30 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13754412#comment-13754412
 ] 

David Smiley commented on SOLR-5084:


bq. If you are worried about idiot users, add a comment around the field type 
to the example:

+1  A comment suffices.

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
 Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, 
 Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-29 Thread Elran Dvir (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13753736#comment-13753736
]

Elran Dvir commented on SOLR-5084:
--

Hi all,

I attached a new patch.
The patch is based on trunk.
It contains changes regarding the issues Robert mentioned (Thanks Robert):
1. fixed the bug where string inputs weren't mapped into their numeric values
in ValueSourceScorer.getRangeScorer and getRangeQuery
2. removed analysis chain.

In the next following days, I will attach fixes for the remaining issues:
1.Verify value strictness on startup (numeric values start at 0, increment by
1).
2.Throwing exception when indexed value is not in the configuration (either
number or string).

Thank you all.

new field type - EnumField
--

Key: SOLR-5084
URL: https://issues.apache.org/jira/browse/SOLR-5084
Project: Solr
Issue Type: New Feature
Reporter: Elran Dvir
Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch,
Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-29 Thread Robert Muir (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13753786#comment-13753786
]

Robert Muir commented on SOLR-5084:
---

{quote}
As long as the config forces them to be explicit about the values (and has
error checking at startup that the values start a 0 and are monotomicly
increasing ints) then anyone who wants to insert values into their config is
going to have to pause and think about the fact that there is a concrete int
associated with the existing values – and is more likely to realize that
changing those ints has consequences.
{quote}

If the values are implicitly 0, 1, 2, ... n, then why force the user to write
that out?

If you are worried about idiot users, add a comment around the field type to
the example:

{code}
!-- note: you cannot change the order/existing values without reindexing.
but you can always add new values to the end. --
{code}

Otherwise it just makes the configuration overly verbose to have them write
0..n themselves.

new field type - EnumField
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-28 Thread Elran Dvir (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13752306#comment-13752306
 ] 

Elran Dvir commented on SOLR-5084:
--

Hi Erick,

I developed the feature with Solr 4.2.1 source code.
I can create a similar patch based on Solr 4.4. Do you want me to create and 
attach it?

Thanks.

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
 Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, 
 Solr-5084.patch, Solr-5084.patch, Solr-5084.patch


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-28 Thread Erick Erickson (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13752321#comment-13752321
]

Erick Erickson commented on SOLR-5084:
--

Yeah, if you would Actually, 4x (eventually 4.5) would be
better, and against trunk would be even best. Uf/when we
apply it we'll merge it into the 4x branch.

But also take a look at Robert's latest comments, he's one
of the deep-level Lucene knowledge.

Best
Erick

new field type - EnumField
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-28 Thread Hoss Man (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13752659#comment-13752659
]

Hoss Man commented on SOLR-5084:

bq. And I still would really like it if we didn't need a separate XML file for
each enumerated type: its like a parallel schema.xml: I think it would be much
better if we could nest this underneath the fieldtype.

it would be nice, but as far as i know there is no way for a FieldType to do
this -- making this FieldType use an attribute to refer to another file (just
like ExternalFile field does, or StopWordsFilterFactory, or
SynonymFilterFactory, etc...) seems like a suitable approach for now, and
if/when someone enhances FieldType configuration in general, then it can be
revisted. (ie: it doesn't seem fair to Elran to object to this patch/feature
given that he's working iwth the APIs available)

bq. Finally, I still think the ordinals should be implicit in the list (as i
mentioned before). This way the thing can actually be efficient.

I agree that it makes sense to require that the ordinals be dense (ie: start
at 0, no gaps allowed).

But in my opinion, from a usability standpoint, I think it's actually better to
force the Solr admin writing the config to explicit about the numeric mappings
in the config so that they *have* to be aware of the fact that a specific
numeric value is used under the covers (ie: in hte indexed/docValues fields)
for each value that the end users get. It seems like it will help minimize the
risk of someone assuming that only the labels matter in the configs and the
can insert new ones to get the sorting they want.

Example:

If the config looked like this...

{noformat}
enum name=priority
valueLOW/value
valueHIGH/value
/enum
{noformat}

...then a user might not realize there is anything wrong with making the
following additions w/o re-indexing...

{noformat}
enum name=priority
valueNONE/value
valueLOW/value
valueMEDIUM/value
valueHIGH/value
/enum
{noformat}

...and if they did that they would silently get bogus results -- no obvious
error at runtime.

As long as the config forces them to be explicit about the values (and has
error checking at startup that the values start a 0 and are monotomicly
increasing ints) then anyone who wants to insert values into their config is
going to have to pause and think about the fact that there is a concrete int
associated with the existing values -- and is more likely to realize that
changing those ints has consequences.

new field type - EnumField
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-27 Thread Elran Dvir (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13751202#comment-13751202
 ] 

Elran Dvir commented on SOLR-5084:
--

Hi,

I have attached a patch containing unit tests.

Thanks.

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
 Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, 
 Solr-5084.patch, Solr-5084.patch, Solr-5084.patch


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-27 Thread Erick Erickson (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13751916#comment-13751916
 ] 

Erick Erickson commented on SOLR-5084:
--

Hmmm, it doesn't apply cleanly to 4x or trunk. Usually patches are made against 
trunk and back-ported/merged to 4x BTW

[~rcmuir]
[~hossman_luc...@fucit.org]
Aside from applying cleanly to the current 4x and trunk, what do you think 
about the current state of the patch?

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
 Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, 
 Solr-5084.patch, Solr-5084.patch, Solr-5084.patch


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-27 Thread Robert Muir (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13751933#comment-13751933
]

Robert Muir commented on SOLR-5084:
---

I still really don't think we should add an enumerated type that isn't strict
about inputs actually matching enumerated values: it loses all of its value to
me.

There are a few inconsistencies where string inputs aren't mapped into their
numeric value: like ValueSourceScorer.getRangeScorer and getRangeQuery in the
fieldtype (in some cases).

I don't understand the need for an analysis chain: The TrieTokenizerFactory is
unnecessary and I have a patch to remove it on some issue somewhere but just
havent gotten around to committing it.

And I still would really like it if we didn't need a separate XML file for each
enumerated type: its like a parallel schema.xml: I think it would be much
better if we could nest this underneath the fieldtype.

Finally, I still think the ordinals should be implicit in the list (as i
mentioned before). This way the thing can actually be efficient.

new field type - EnumField
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-21 Thread Erick Erickson (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13746521#comment-13746521
]

Erick Erickson commented on SOLR-5084:
--

I have a few cycles to devote to this.

[~elrand] What's the state of the most recent patch? You were going to attach a
new patch that had some unit tests, is that forthcoming or did I miss it being
attached?

new field type - EnumField
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-21 Thread Elran Dvir (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13747249#comment-13747249
]

Elran Dvir commented on SOLR-5084:
--

In the latest patch I removed all redundant format changes. There were no
changes in logic.
I hope to attach the patch with unit tests in the next following days.

Thanks again for the attention.

new field type - EnumField
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-13 Thread Elran Dvir (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13738031#comment-13738031
 ] 

Elran Dvir commented on SOLR-5084:
--

The patch is finally attached.
I'll attach a patch with unit tests ASAP. 

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
 Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, 
 Solr-5084.patch, Solr-5084.patch


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-13 Thread Erick Erickson (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13738092#comment-13738092
]

Erick Erickson commented on SOLR-5084:
--

@Elran

bq: Why do you say the assumption is the type is restricted to single value?...

Parts of the discussion mentioned sorting, which is undefined on multivalued
fields. If sorting is _required_ for an enum-type field then it shouldn't be
mutliValued. There's no reason it _needs_ to be restricted to single values,
it's fine for the enum type to be just like any other field; it's up to the
user to only put one value in the field if it's to be used to sorting.

Mostly getting it straight in my head what the characteristics are, not saying
it _should_ be single-valued-only...

Erick

new field type - EnumField
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-13 Thread Robert Muir (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13738096#comment-13738096
]

Robert Muir commented on SOLR-5084:
---

Wait: i said sort order (not sorting).

So to me the multivalued case of an enum field makes total sense (it is kinda
like java's EnumSet). And the sort order defines what is used in faceting,
range queries, and so on.

new field type - EnumField
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-13 Thread Erick Erickson (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13738098#comment-13738098
]

Erick Erickson commented on SOLR-5084:
--

Ahhh, OK. Then Hoss says sorting, so no wonder I'm confused!

There's no reason one couldn't sort by a field of this type, right? Frankly
though, it seems kind of low-utility since there are probably only going to be
a few values in the common use-case, but I'd guess it's still a possibility...

new field type - EnumField
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-13 Thread Robert Muir (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13738106#comment-13738106
]

Robert Muir commented on SOLR-5084:
---

I think sorting is a major use case. With some of these previous examples like
risk or issue tracker status, you want to sort by the field and for 'high' risk
to sort after 'low', maybe 'closed' after 'created' and so on.

new field type - EnumField
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-12 Thread Elran Dvir (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736975#comment-13736975
]

Elran Dvir commented on SOLR-5084:
--

Thank you all very much for your very quick feedback.

@Hoss,

1) I eliminated all formatting changes and attached a new patch. I hope
it'll be more readable now.
2) I will try to create unit test as soon as possible and attach it.
3) I returned the value as EnumFieldValue in JavaBin format because I
would like to allow for a use case of sorting the values when returned to my
application by SolrJ.
4) Maybe it could, but I tried to keep the implementation simple and it
didn’t appear to give much more value. If someone feels strongly about it I can
revisit the implementation

@Robert,

In the configuration, I chose to specify the numeric values because I want
to also enable indexing and querying numeric values.
For example, the queries risk:[1 TO 3] and risk:[Low TO High] are both
valid.
Currently:
- If a bogus string value is sent, the value is indexed as -1.
- If a bogus integer value is sent, if the value is not a negative
number, the value is indexed as is. If it’s negative – the value is indexed as
-1.
- The display value is of course string. If we don’t find a matching
label to the numeric value in the configuration, the actual numeric value is
displayed.
Adding a new value at the end, would work.
Changing a display string for a value, will also work for retrieving data –
new data will have to be inserted using the new name (or by int value)
Removing a legal value from the list would retrieve the numeric value for
existing data

I have no use case for removing a previously legal value, so I can either
document the behavior, or implement a different behavior – depending on how
this discussion goes

@Erick,

I didn't intend to make this type single valued on purpose, it’s just that my
use case is single valued. I changed the field's configuration to multi value
and it seems to work fine
(facet, pivot, stats, return stored field). Why do you say the assumption is
the type is restricted to single value?
Thanks again.

new field type - EnumField
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-12 Thread Elran Dvir (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736990#comment-13736990
 ] 

Elran Dvir commented on SOLR-5084:
--

I failed attaching the new patch. I will attach it ASAP.
The only changes are formatting. 

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
 Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, 
 Solr-5084.patch


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-09 Thread Erick Erickson (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13734741#comment-13734741
]

Erick Erickson commented on SOLR-5084:
--

H...

So the underlying assumption here is that the enum type is restricted to being
single valued. Not saying it should be multiValued, just making sure it's
explicit.

Hoss's point about inserting/removing values in the middle of the list leading
to interesting behavior is well taken, but I'd rather deal with that by big
fat warnings in the documentation, telling users they need to re-index. Let's
wait for the compelling use-case before complexifying it...

FWIW

new field type - EnumField
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-08 Thread Hoss Man (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13734159#comment-13734159
 ] 

Hoss Man commented on SOLR-5084:


Elran:

1) there's still several sections in your patch that have a lot of reformatting 
making it hard to see what exactly you've added.  (I realize that the 
formatting may not be 100% uniform in all of these files, but the key to making 
patches easy to read is not to change anything that does't *have* to be changed 
... formatting changes should be done seperately and independently from 
functionality changes)

2) could you please add a few unit tests to show how the type can be used when 
indexing/querying/faceting/returning stored fields so it's more clear what this 
patch does?

3) I'm not sure that it makes sense to customize the response writers and the 
JavaBinCodec to know about hte enum values -- it seems like it would make a lot 
more sense (and by much simpler) to have clients just treat the enum values as 
strings

4) a lot of your code seems to be cut/paste from TrieField ... why can't the 
EnumField class subclass TrieField to re-use this behavior (or worst case: wrap 
a TrieIntField similar to how TrieDateField works)

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
 Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, 
 Solr-5084.patch


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-08 Thread Robert Muir (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13734178#comment-13734178
]

Robert Muir commented on SOLR-5084:
---

I agree with Hossman.. stick with it though, I really like the idea of an
efficient enumerated type.

A few other ideas/questions (just from a glance, i could be wrong):
* should we enforce from the enum config that the integer values are 0-N or
something simple? This way, things like valuesources dont have to do hashing
but simple array lookups.
* it isnt clear to me what happens if you send a bogus value. I think an
enumerated type would be best if its strongly-typed and just throws exception
if the value is bogus.
* should the config, instead of being a separate config file, just be a nested
element underneath the field type? I dont know if this is even possible or a
good idea, but its an that would remove some xml files.

new field type - EnumField
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-08 Thread Hoss Man (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13734210#comment-13734210
]

Hoss Man commented on SOLR-5084:

bq. ...nested element underneath the field type? I dont know if this is even
possible or a good idea, but its an that would remove some xml files.

i don't think the schema parsing code can handle that -- it's attribute based,
not nested element based

bq. should we enforce from the enum config that the integer values are 0-N or
something simple? ...

yeah ... it would be tempting to not even let the config specify numeric values
-- just an ordered list, except:

1) all hell would break loose if someone accidently inserted a new element
anywhere other then the end of the list
2) you'd need/want a way to disable values form the middle of the list from
working again.

#2 is a problem you'd need to worry about even if we keep the mappings explicit
but enforce 0-N ... there needs to be something like...

{code}
enum name=severity
pair name=Not Available value=0/
pair name=Low value=1/

!-- value w/o name passes validation but prevents it from being used --
pair value=2/ !-- Medium use to exist, but was phased out --

pair name=High value=3/
pair name=Critical value=4/

!-- this however would fail, because we skipped 5-10 --
pair name=Super Nova value=11/
/enum
{code}

bq. ... This way, things like valuesources dont have to do hashing but simple
array lookups.

I was actually thinking it would be nice to support multiple legal names (with
one canonical for respones) per value, but that would preent the simple array
lookps...

{code}
enum name=severity
value int=0labelNot Available/label/value
value int=1labelLow/label/value

!-- value w/o name passes validation but prevents it from being used --
value int=2 / !-- Medium use to exist, but was phased out --

value int=3labelHigh/label/value

value int=4
label canonical=trueCritical/label
labelHighest/label
/value
/enum
{code}

new field type - EnumField
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-08 Thread Robert Muir (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13734223#comment-13734223
]

Robert Muir commented on SOLR-5084:
---

{quote}
...nested element underneath the field type? I dont know if this is even
possible or a good idea, but its an that would remove some xml files.

i don't think the schema parsing code can handle that – it's attribute based,
not nested element based
{quote}

Right but code can change. Other parts of solr allow this kinda stuff.

{quote}
yeah ... it would be tempting to not even let the config specify numeric values
– just an ordered list, except:

Well i guess i look at it differently. That this is in a sense like an
analyzer. you cant change the config without reindexing.

{quote}
I was actually thinking it would be nice to support multiple legal names (with
one canonical for respones) per value, but that would preent the simple array
lookps...
{quote}

Why? I'm talking about int-canonical name (e.g. in the valuesource impl) not
anything else. as far as name-int, you want a hash anyway.

new field type - EnumField
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-08 Thread Hoss Man (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13734228#comment-13734228
]

Hoss Man commented on SOLR-5084:

bq. Well i guess i look at it differently. That this is in a sense like an
analyzer. you cant change the config without reindexing.

i dunno ... that seems like it would really kill the utility of a field for a
lot of use cases -- if it had that kind of limitation, i would just use an
int field an managing the mappings myself so id always know i could
add/remove fields w/o needing to reindex.

to follow your example: if i completley change hte analyzer, then yes i have ot
reindex -- but if want to stop using a ynonym, i don't have to re-index every
doc, just the ones that had that used that synonyms.

bq. as far as name-int, you want a hash anyway.

right ... never mind, i was thinking about it backwards.

new field type - EnumField
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-08 Thread Robert Muir (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13734239#comment-13734239
]

Robert Muir commented on SOLR-5084:
---

{quote}
i dunno ... that seems like it would really kill the utility of a field for a
lot of use cases – if it had that kind of limitation, i would just use an int
field an managing the mappings myself so id always know i could add/remove
(EDIT) fields values w/o needing to reindex.
{quote}

This isnt really going to work here, because the idea is you want to assign
sort order (not just values mapped to ints). If you want to rename a label,
thats fine, but you cant really change the sort order without reindexing.

new field type - EnumField
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-08 Thread Hoss Man (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13734248#comment-13734248
]

Hoss Man commented on SOLR-5084:

bq. If you want to rename a label, thats fine, but you cant really change the
sort order without reindexing.

No, no .. of course not ... i wasn't suggestiong you could change the order,
just:
* *remove* a legal value from the list (w/o causing hte validation to complain)
* add new values to the end of the list
* (as you mentioned) modify the label on an existing value

See the example i posted before about removing Medium but keeping High
Critical exactly as they are -- no change in indexed data, just a way to tell
the validation logic you were talking about adding skip this value, i removed
it on purpose (or i suppose: skip this value, i'm reserving it as a
placeholder for future use)

new field type - EnumField
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-08 Thread Robert Muir (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13734254#comment-13734254
]

Robert Muir commented on SOLR-5084:
---

I think adding new values to the end of the list is no issue at all. neither is
renaming labels.

but removing a legal value from the list, i think you need to reindex. Because
what to do with documents that have that integer value?

in general i'm just trying to make sure we keep things sane here, so that the
underlying shit is efficient.

new field type - EnumField
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-08 Thread Hoss Man (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13734259#comment-13734259
]

Hoss Man commented on SOLR-5084:

bq. but removing a legal value from the list, i think you need to reindex.
Because what to do with documents that have that integer value?

For sorting and value sources etc... nothing special happens -- they still have
the same numeric value under the covers; it's just that when writing out the
stored values (ie: label) you act as if they have no value in the field at
all (shouldn't affect efficiency at all.)

If the user wants some other behavior the burden is on them to re-index or
delete the affected docs -- but the simple stuff stays just as simple as if
they were dealing with the int-label mappings in their own code, the
validation of legal labels just moves from the client to solr.

new field type - EnumField
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-08 Thread Robert Muir (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13734266#comment-13734266
]

Robert Muir commented on SOLR-5084:
---

{quote}
For sorting and value sources etc... nothing special happens – they still have
the same numeric value under the covers; it's just that when writing out the
stored values (ie: label) you act as if they have no value in the field at
all (shouldn't affect efficiency at all.)
{quote}

Then this is just renaming a label to some special value.

I really think the best thing is to keep it simple, like java.lang.Enum. Just
give a list of values. This way it will be efficient everywhere since the
values will be dense. Its also conceptually simple.

Otherwise, things get complicated. and the implementation may suffer due to
sparse ordinals. Really, i dont care, as docvalues will do the right thing as
long as you have 256 values (regardless of sparsity). Fieldcache wont, but
doesn't bother me a bit.

But still, there is no sense in making things complicated and inefficient for
no good reason. Someone could make a HairyComplicatedAndInefficientEnumType for
that.

new field type - EnumField
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-08-01 Thread Elran Dvir (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726151#comment-13726151
 ] 

Elran Dvir commented on SOLR-5084:
--

I reformatted the code.
I hope it's OK now.

Thanks. 

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
 Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, 
 Solr-5084.patch


 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-07-31 Thread Robert Muir (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13725456#comment-13725456
]

Robert Muir commented on SOLR-5084:
---

This issue is interesting but its difficult to see the changes due to all the
reformatting in the patch (e.g. changing existing 2-space indent to 4-space
indent).

Is it possible to fix this in the patch? See
http://wiki.apache.org/solr/HowToContribute#Creating_the_patch_file

Thanks

new field type - EnumField
--

Key: SOLR-5084
URL: https://issues.apache.org/jira/browse/SOLR-5084
Project: Solr
Issue Type: New Feature
Reporter: Elran Dvir
Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5084) new field type - EnumField

2013-07-28 Thread Jack Krupansky (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13721981#comment-13721981
 ] 

Jack Krupansky commented on SOLR-5084:
--

Hmmm... I'm wondering how this might tie in with Lucene faceted fields - 
optimized for a limited number of values.

 new field type - EnumField
 --

 Key: SOLR-5084
 URL: https://issues.apache.org/jira/browse/SOLR-5084
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir

 We have encountered a use case in our system where we have a few fields 
 (Severity. Risk etc) with a closed set of values, where the sort order for 
 these values is pre-determined but not lexicographic (Critical is higher than 
 High). Generically this is very close to how enums work.
 To implement, I have prototyped a new type of field: EnumField where the 
 inputs are a closed predefined  set of strings in a special configuration 
 file (similar to currency.xml).
 The code is based on 4.2.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

50 matches

Mail list logo