Congrats Chris!
I vote for thinkAboutNotIncludingNormsMaybe(true|false) <G>.....
Seriously double negatives are ugly IMO, +1 for changing....
Erick
On Fri, Mar 12, 2010 at 12:56 PM, Chris Male (JIRA) <jira@apache.org> wrote:
[
https://issues.apache.org/jira/browse/LUCENE-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844587#action_12844587]
Chris Male commented on LUCENE-2308:
------------------------------------
I agree entirely. This is definitely the moment to remove any ambiguity or
confusion in this API. I'll make sure to incorporate this idea.
Separately specify a field's type
---------------------------------
Key: LUCENE-2308
URL: https://issues.apache.org/jira/browse/LUCENE-2308
Project: Lucene - Java
Issue Type: Improvement
Components: Index
Reporter: Michael McCandless
This came up from dicussions on IRC. I'm summarizing here...
Today when you make a Field to add to a document you can set things
index or not, stored or not, analyzed or not, details like omitTfAP,
omitNorms, index term vectors (separately controlling
offsets/positions), etc.
I think we should factor these out into a new class (FieldType?).
Then you could re-use this FieldType instance across multiple fields.
The Field instance would still hold the actual value.
We could then do per-field analyzers by adding a setAnalyzer on the
FieldType, instead of the separate PerFieldAnalzyerWrapper (likewise
for per-field codecs (with flex), where we now have
PerFieldCodecWrapper).
This would NOT be a schema! It's just refactoring what we already
specify today. EG it's not serialized into the index.
This has been discussed before, and I know Michael Busch opened a more
ambitious (I think?) issue. I think this is a good first baby step. We
could
consider a hierarchy of FIeldType (NumericFieldType, etc.) but maybe hold
off on that for starters...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Congrats Chris!<div><br></div><div>I vote for thinkAboutNotIncludingNormsMaybe(true|false) <G>.....</div><div><br></div><div>Seriously double negatives are ugly IMO, +1 for changing....</div><div><br></div><div>Erick<br>
<br><div class="gmail_quote">On Fri, Mar 12, 2010 at 12:56 PM, Chris Male (JIRA) <span dir="ltr"><<a href="mailto:jira@apache.org">jira@apache.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
[ <a href="https://issues.apache.org/jira/browse/LUCENE-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844587#action_12844587" target="_blank">https://issues.apache.org/jira/browse/LUCENE-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844587#action_12844587</a> ]<br>
<div class="im"><br>
Chris Male commented on LUCENE-2308:<br>
------------------------------------<br>
<br>
</div>I agree entirely. This is definitely the moment to remove any ambiguity or confusion in this API. I'll make sure to incorporate this idea.<br>
<div><div></div><div class="h5"><br>
> Separately specify a field's type<br>
> ---------------------------------<br>
><br>
> Key: LUCENE-2308<br>
> URL: <a href="https://issues.apache.org/jira/browse/LUCENE-2308" target="_blank">https://issues.apache.org/jira/browse/LUCENE-2308</a><br>
> Project: Lucene - Java<br>
> Issue Type: Improvement<br>
> Components: Index<br>
> Reporter: Michael McCandless<br>
><br>
> This came up from dicussions on IRC. I'm summarizing here...<br>
> Today when you make a Field to add to a document you can set things<br>
> index or not, stored or not, analyzed or not, details like omitTfAP,<br>
> omitNorms, index term vectors (separately controlling<br>
> offsets/positions), etc.<br>
> I think we should factor these out into a new class (FieldType?).<br>
> Then you could re-use this FieldType instance across multiple fields.<br>
> The Field instance would still hold the actual value.<br>
> We could then do per-field analyzers by adding a setAnalyzer on the<br>
> FieldType, instead of the separate PerFieldAnalzyerWrapper (likewise<br>
> for per-field codecs (with flex), where we now have<br>
> PerFieldCodecWrapper).<br>
> This would NOT be a schema! It's just refactoring what we already<br>
> specify today. EG it's not serialized into the index.<br>
> This has been discussed before, and I know Michael Busch opened a more<br>
> ambitious (I think?) issue. I think this is a good first baby step. We could<br>
> consider a hierarchy of FIeldType (NumericFieldType, etc.) but maybe hold<br>
> off on that for starters...<br>
<br>
--<br>
This message is automatically generated by JIRA.<br>
-<br>
You can reply to this email to add a comment to the issue online.<br>
<br>
<br>
---------------------------------------------------------------------<br>
To unsubscribe, e-mail: <a href="mailto:java-dev-unsubscribe@lucene.apache.org">java-dev-unsubscribe@lucene.apache.org</a><br>
For additional commands, e-mail: <a href="mailto:java-dev-help@lucene.apache.org">java-dev-help@lucene.apache.org</a><br>
<br>
</div></div></blockquote></div><br></div>
