[jira] Commented: (SOLR-1664) Some Methods in FieldType actually should be in SchemaField
[
https://issues.apache.org/jira/browse/SOLR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792855#action_12792855
]
Yonik Seeley commented on SOLR-1664:
I like the direction I think... the current split between SchemaField and
FieldType forces one to often use the following pattern:
schemaField.type().soSomething(schemaField,...)
I do think FieldType should basically become the factory for SchemaField.
FieldType methods not having to do with parsing parameters and creating
SchemaFields should be deprecated and those we want to keep (i.e. not all of
them) should be moved to SchemaField. All creation of SchemaField instances
should go through the appropriate FieldType. All code in Solr that dispatches
through FieldType should be changed to dispatch through the SchemaField
instance.
This should lead to slightly cleaner code overall. The downside is really that
it doesn't end up accomplish much at all for the end user of Solr.
Some Methods in FieldType actually should be in SchemaField
---
Key: SOLR-1664
URL: https://issues.apache.org/jira/browse/SOLR-1664
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Fix For: 1.5
Attachments: SOLR-1664.patch
The following methods are only overridable from FieldType.
{code:java}
public Field createField(SchemaField field, String externalVal, float boost) ;
protected Field.TermVector getFieldTermVec(SchemaField field,String
internalVal) ;
protected Field.Store getFieldStore(SchemaField field,String internalVal);
protected Field.Index getFieldIndex(SchemaField field,String internalVal);
public ValueSource getValueSource(SchemaField field, QParser parser);
public Query getRangeQuery(QParser parser, SchemaField field, String part1,
String part2, boolean minInclusive, boolean maxInclusive) ;
{code}
if there is anything specific to be done on a per-field basis it is not
possible. if we allow overriding SchemaField it will be more flexible.
I hope this can make it simpler to implement SOLR-1131
So ,there are two ways of overriding a functionality.
* Override Fieldtype#createSchemaField() and provide new implementation of
SchemaField
* Override methods from FieldType itself(if the behavior is not per field )
as it is now
SchemaField is made non-final and Solr only invokes methods on SchemaField
and not FieldType directly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1664) Some Methods in FieldType actually should be in SchemaField
[
https://issues.apache.org/jira/browse/SOLR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792885#action_12792885
]
Noble Paul commented on SOLR-1664:
--
yes. cleaner code is definitely a plus
Some Methods in FieldType actually should be in SchemaField
---
Key: SOLR-1664
URL: https://issues.apache.org/jira/browse/SOLR-1664
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Fix For: 1.5
Attachments: SOLR-1664.patch
The following methods are only overridable from FieldType.
{code:java}
public Field createField(SchemaField field, String externalVal, float boost) ;
protected Field.TermVector getFieldTermVec(SchemaField field,String
internalVal) ;
protected Field.Store getFieldStore(SchemaField field,String internalVal);
protected Field.Index getFieldIndex(SchemaField field,String internalVal);
public ValueSource getValueSource(SchemaField field, QParser parser);
public Query getRangeQuery(QParser parser, SchemaField field, String part1,
String part2, boolean minInclusive, boolean maxInclusive) ;
{code}
if there is anything specific to be done on a per-field basis it is not
possible. if we allow overriding SchemaField it will be more flexible.
I hope this can make it simpler to implement SOLR-1131
So ,there are two ways of overriding a functionality.
* Override Fieldtype#createSchemaField() and provide new implementation of
SchemaField
* Override methods from FieldType itself(if the behavior is not per field )
as it is now
SchemaField is made non-final and Solr only invokes methods on SchemaField
and not FieldType directly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1664) Some Methods in FieldType actually should be in SchemaField
[
https://issues.apache.org/jira/browse/SOLR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792498#action_12792498
]
Yonik Seeley commented on SOLR-1664:
bq. The point is , if we wish to go down this path , this is the best
opportunity to do that because, SOLR-1131 is introducing wholesale changes to
the FieldType API
I'm reviewing/changing SOLR-1131 now to actually limit the public interface
changes to two methods: isPolyFIeld() and createFields(). It's not being
changed much at all.
I'm not against this change, but I think this issue should stand on it's own
and not be linked to SOLR-1131.
Some Methods in FieldType actually should be in SchemaField
---
Key: SOLR-1664
URL: https://issues.apache.org/jira/browse/SOLR-1664
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Fix For: 1.5
Attachments: SOLR-1664.patch
The following methods are only overridable from FieldType.
{code:java}
public Field createField(SchemaField field, String externalVal, float boost) ;
protected Field.TermVector getFieldTermVec(SchemaField field,String
internalVal) ;
protected Field.Store getFieldStore(SchemaField field,String internalVal);
protected Field.Index getFieldIndex(SchemaField field,String internalVal);
public ValueSource getValueSource(SchemaField field, QParser parser);
public Query getRangeQuery(QParser parser, SchemaField field, String part1,
String part2, boolean minInclusive, boolean maxInclusive) ;
{code}
if there is anything specific to be done on a per-field basis it is not
possible. if we allow overriding SchemaField it will be more flexible.
I hope this can make it simpler to implement SOLR-1131
So ,there are two ways of overriding a functionality.
* Override Fieldtype#createSchemaField() and provide new implementation of
SchemaField
* Override methods from FieldType itself(if the behavior is not per field )
as it is now
SchemaField is made non-final and Solr only invokes methods on SchemaField
and not FieldType directly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1664) Some Methods in FieldType actually should be in SchemaField
[
https://issues.apache.org/jira/browse/SOLR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792503#action_12792503
]
Noble Paul commented on SOLR-1664:
--
bq.this issue should stand on it's own and not be linked to SOLR-1131.
agreed. It is just that SOLR-1131 has serendipitously exposed a shortcoming in
the API .
Some Methods in FieldType actually should be in SchemaField
---
Key: SOLR-1664
URL: https://issues.apache.org/jira/browse/SOLR-1664
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Fix For: 1.5
Attachments: SOLR-1664.patch
The following methods are only overridable from FieldType.
{code:java}
public Field createField(SchemaField field, String externalVal, float boost) ;
protected Field.TermVector getFieldTermVec(SchemaField field,String
internalVal) ;
protected Field.Store getFieldStore(SchemaField field,String internalVal);
protected Field.Index getFieldIndex(SchemaField field,String internalVal);
public ValueSource getValueSource(SchemaField field, QParser parser);
public Query getRangeQuery(QParser parser, SchemaField field, String part1,
String part2, boolean minInclusive, boolean maxInclusive) ;
{code}
if there is anything specific to be done on a per-field basis it is not
possible. if we allow overriding SchemaField it will be more flexible.
I hope this can make it simpler to implement SOLR-1131
So ,there are two ways of overriding a functionality.
* Override Fieldtype#createSchemaField() and provide new implementation of
SchemaField
* Override methods from FieldType itself(if the behavior is not per field )
as it is now
SchemaField is made non-final and Solr only invokes methods on SchemaField
and not FieldType directly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1664) Some Methods in FieldType actually should be in SchemaField
[
https://issues.apache.org/jira/browse/SOLR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792780#action_12792780
]
Noble Paul commented on SOLR-1664:
--
* Are we in consensus that this is going in?
* Any further changes required for the patch?
Some Methods in FieldType actually should be in SchemaField
---
Key: SOLR-1664
URL: https://issues.apache.org/jira/browse/SOLR-1664
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Fix For: 1.5
Attachments: SOLR-1664.patch
The following methods are only overridable from FieldType.
{code:java}
public Field createField(SchemaField field, String externalVal, float boost) ;
protected Field.TermVector getFieldTermVec(SchemaField field,String
internalVal) ;
protected Field.Store getFieldStore(SchemaField field,String internalVal);
protected Field.Index getFieldIndex(SchemaField field,String internalVal);
public ValueSource getValueSource(SchemaField field, QParser parser);
public Query getRangeQuery(QParser parser, SchemaField field, String part1,
String part2, boolean minInclusive, boolean maxInclusive) ;
{code}
if there is anything specific to be done on a per-field basis it is not
possible. if we allow overriding SchemaField it will be more flexible.
I hope this can make it simpler to implement SOLR-1131
So ,there are two ways of overriding a functionality.
* Override Fieldtype#createSchemaField() and provide new implementation of
SchemaField
* Override methods from FieldType itself(if the behavior is not per field )
as it is now
SchemaField is made non-final and Solr only invokes methods on SchemaField
and not FieldType directly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1664) Some Methods in FieldType actually should be in SchemaField
[
https://issues.apache.org/jira/browse/SOLR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791884#action_12791884
]
Grant Ingersoll commented on SOLR-1664:
---
createField is already just a pass through to the type. I'm not so sure about
making these changes just yet. Let's see how SOLR-1131 plays out. In my
testing, the concerns over that field creation are minimal. It's cheaper than
a dynamic field.
Some Methods in FieldType actually should be in SchemaField
---
Key: SOLR-1664
URL: https://issues.apache.org/jira/browse/SOLR-1664
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Fix For: 1.5
Attachments: SOLR-1664.patch
The following methods are only overridable from FieldType.
{code:java}
public Field createField(SchemaField field, String externalVal, float boost) ;
protected Field.TermVector getFieldTermVec(SchemaField field,String
internalVal) ;
protected Field.Store getFieldStore(SchemaField field,String internalVal);
protected Field.Index getFieldIndex(SchemaField field,String internalVal);
public ValueSource getValueSource(SchemaField field, QParser parser);
public Query getRangeQuery(QParser parser, SchemaField field, String part1,
String part2, boolean minInclusive, boolean maxInclusive) ;
{code}
if there is anything specific to be done on a per-field basis it is not
possible. if we allow overriding SchemaField it will be more flexible.
I hope this can make it simpler to implement SOLR-1131
So ,there are two ways of overriding a functionality.
* Override Fieldtype#createSchemaField() and provide new implementation of
SchemaField
* Override methods from FieldType itself(if the behavior is not per field )
as it is now
SchemaField is made non-final and Solr only invokes methods on SchemaField
and not FieldType directly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1664) Some Methods in FieldType actually should be in SchemaField
[
https://issues.apache.org/jira/browse/SOLR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791892#action_12791892
]
Noble Paul commented on SOLR-1664:
--
bq.It's cheaper than a dynamic field.
I cannot see this point. How can it be cheap when you are creating a new String
(the syntehtic name) for each field for each query and insert?
Object creation is usually fast but ends up consuming a lot of memory. This can
enable us to have an efficient design
Some Methods in FieldType actually should be in SchemaField
---
Key: SOLR-1664
URL: https://issues.apache.org/jira/browse/SOLR-1664
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Fix For: 1.5
Attachments: SOLR-1664.patch
The following methods are only overridable from FieldType.
{code:java}
public Field createField(SchemaField field, String externalVal, float boost) ;
protected Field.TermVector getFieldTermVec(SchemaField field,String
internalVal) ;
protected Field.Store getFieldStore(SchemaField field,String internalVal);
protected Field.Index getFieldIndex(SchemaField field,String internalVal);
public ValueSource getValueSource(SchemaField field, QParser parser);
public Query getRangeQuery(QParser parser, SchemaField field, String part1,
String part2, boolean minInclusive, boolean maxInclusive) ;
{code}
if there is anything specific to be done on a per-field basis it is not
possible. if we allow overriding SchemaField it will be more flexible.
I hope this can make it simpler to implement SOLR-1131
So ,there are two ways of overriding a functionality.
* Override Fieldtype#createSchemaField() and provide new implementation of
SchemaField
* Override methods from FieldType itself(if the behavior is not per field )
as it is now
SchemaField is made non-final and Solr only invokes methods on SchemaField
and not FieldType directly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1664) Some Methods in FieldType actually should be in SchemaField
[
https://issues.apache.org/jira/browse/SOLR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791911#action_12791911
]
Grant Ingersoll commented on SOLR-1664:
---
I've got a new patch that reduces the string allocation costs. These objects
are very short lived. I did some profiling and it barely even measures a blip.
Some Methods in FieldType actually should be in SchemaField
---
Key: SOLR-1664
URL: https://issues.apache.org/jira/browse/SOLR-1664
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Fix For: 1.5
Attachments: SOLR-1664.patch
The following methods are only overridable from FieldType.
{code:java}
public Field createField(SchemaField field, String externalVal, float boost) ;
protected Field.TermVector getFieldTermVec(SchemaField field,String
internalVal) ;
protected Field.Store getFieldStore(SchemaField field,String internalVal);
protected Field.Index getFieldIndex(SchemaField field,String internalVal);
public ValueSource getValueSource(SchemaField field, QParser parser);
public Query getRangeQuery(QParser parser, SchemaField field, String part1,
String part2, boolean minInclusive, boolean maxInclusive) ;
{code}
if there is anything specific to be done on a per-field basis it is not
possible. if we allow overriding SchemaField it will be more flexible.
I hope this can make it simpler to implement SOLR-1131
So ,there are two ways of overriding a functionality.
* Override Fieldtype#createSchemaField() and provide new implementation of
SchemaField
* Override methods from FieldType itself(if the behavior is not per field )
as it is now
SchemaField is made non-final and Solr only invokes methods on SchemaField
and not FieldType directly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1664) Some Methods in FieldType actually should be in SchemaField
[
https://issues.apache.org/jira/browse/SOLR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791927#action_12791927
]
Grant Ingersoll commented on SOLR-1664:
---
I think SchemaField needs to remain final. I don't think we should be allowing
people to extend SchemaField.
Some Methods in FieldType actually should be in SchemaField
---
Key: SOLR-1664
URL: https://issues.apache.org/jira/browse/SOLR-1664
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Fix For: 1.5
Attachments: SOLR-1664.patch
The following methods are only overridable from FieldType.
{code:java}
public Field createField(SchemaField field, String externalVal, float boost) ;
protected Field.TermVector getFieldTermVec(SchemaField field,String
internalVal) ;
protected Field.Store getFieldStore(SchemaField field,String internalVal);
protected Field.Index getFieldIndex(SchemaField field,String internalVal);
public ValueSource getValueSource(SchemaField field, QParser parser);
public Query getRangeQuery(QParser parser, SchemaField field, String part1,
String part2, boolean minInclusive, boolean maxInclusive) ;
{code}
if there is anything specific to be done on a per-field basis it is not
possible. if we allow overriding SchemaField it will be more flexible.
I hope this can make it simpler to implement SOLR-1131
So ,there are two ways of overriding a functionality.
* Override Fieldtype#createSchemaField() and provide new implementation of
SchemaField
* Override methods from FieldType itself(if the behavior is not per field )
as it is now
SchemaField is made non-final and Solr only invokes methods on SchemaField
and not FieldType directly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1664) Some Methods in FieldType actually should be in SchemaField
[
https://issues.apache.org/jira/browse/SOLR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791928#action_12791928
]
Noble Paul commented on SOLR-1664:
--
The questions I have are.
Is this a good enhancement to have? Does it not enable us to have cleaner
implementation of usecases like SOLR-1131 ?
bq.These objects are very short lived.
If we can avoid the creation of Objects that is definitely a better solution.
Are we trying to avoid this because this is not a correct solution?
Some Methods in FieldType actually should be in SchemaField
---
Key: SOLR-1664
URL: https://issues.apache.org/jira/browse/SOLR-1664
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Fix For: 1.5
Attachments: SOLR-1664.patch
The following methods are only overridable from FieldType.
{code:java}
public Field createField(SchemaField field, String externalVal, float boost) ;
protected Field.TermVector getFieldTermVec(SchemaField field,String
internalVal) ;
protected Field.Store getFieldStore(SchemaField field,String internalVal);
protected Field.Index getFieldIndex(SchemaField field,String internalVal);
public ValueSource getValueSource(SchemaField field, QParser parser);
public Query getRangeQuery(QParser parser, SchemaField field, String part1,
String part2, boolean minInclusive, boolean maxInclusive) ;
{code}
if there is anything specific to be done on a per-field basis it is not
possible. if we allow overriding SchemaField it will be more flexible.
I hope this can make it simpler to implement SOLR-1131
So ,there are two ways of overriding a functionality.
* Override Fieldtype#createSchemaField() and provide new implementation of
SchemaField
* Override methods from FieldType itself(if the behavior is not per field )
as it is now
SchemaField is made non-final and Solr only invokes methods on SchemaField
and not FieldType directly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1664) Some Methods in FieldType actually should be in SchemaField
[
https://issues.apache.org/jira/browse/SOLR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791931#action_12791931
]
Noble Paul commented on SOLR-1664:
--
bq.I think SchemaField needs to remain final. I don't think we should be
allowing people to extend SchemaField.
I see no advantage of SchemaField being final.
Some Methods in FieldType actually should be in SchemaField
---
Key: SOLR-1664
URL: https://issues.apache.org/jira/browse/SOLR-1664
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Fix For: 1.5
Attachments: SOLR-1664.patch
The following methods are only overridable from FieldType.
{code:java}
public Field createField(SchemaField field, String externalVal, float boost) ;
protected Field.TermVector getFieldTermVec(SchemaField field,String
internalVal) ;
protected Field.Store getFieldStore(SchemaField field,String internalVal);
protected Field.Index getFieldIndex(SchemaField field,String internalVal);
public ValueSource getValueSource(SchemaField field, QParser parser);
public Query getRangeQuery(QParser parser, SchemaField field, String part1,
String part2, boolean minInclusive, boolean maxInclusive) ;
{code}
if there is anything specific to be done on a per-field basis it is not
possible. if we allow overriding SchemaField it will be more flexible.
I hope this can make it simpler to implement SOLR-1131
So ,there are two ways of overriding a functionality.
* Override Fieldtype#createSchemaField() and provide new implementation of
SchemaField
* Override methods from FieldType itself(if the behavior is not per field )
as it is now
SchemaField is made non-final and Solr only invokes methods on SchemaField
and not FieldType directly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1664) Some Methods in FieldType actually should be in SchemaField
[
https://issues.apache.org/jira/browse/SOLR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791934#action_12791934
]
Grant Ingersoll commented on SOLR-1664:
---
It is not correct b/c SchemaField should be final. What does it even mean to
change a SchemaField? Are the results persisted back to the file? What does
it mean to change the name in the middle of indexing? If you make it public,
those are all things people could do.
Some Methods in FieldType actually should be in SchemaField
---
Key: SOLR-1664
URL: https://issues.apache.org/jira/browse/SOLR-1664
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Fix For: 1.5
Attachments: SOLR-1664.patch
The following methods are only overridable from FieldType.
{code:java}
public Field createField(SchemaField field, String externalVal, float boost) ;
protected Field.TermVector getFieldTermVec(SchemaField field,String
internalVal) ;
protected Field.Store getFieldStore(SchemaField field,String internalVal);
protected Field.Index getFieldIndex(SchemaField field,String internalVal);
public ValueSource getValueSource(SchemaField field, QParser parser);
public Query getRangeQuery(QParser parser, SchemaField field, String part1,
String part2, boolean minInclusive, boolean maxInclusive) ;
{code}
if there is anything specific to be done on a per-field basis it is not
possible. if we allow overriding SchemaField it will be more flexible.
I hope this can make it simpler to implement SOLR-1131
So ,there are two ways of overriding a functionality.
* Override Fieldtype#createSchemaField() and provide new implementation of
SchemaField
* Override methods from FieldType itself(if the behavior is not per field )
as it is now
SchemaField is made non-final and Solr only invokes methods on SchemaField
and not FieldType directly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1664) Some Methods in FieldType actually should be in SchemaField
[
https://issues.apache.org/jira/browse/SOLR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791933#action_12791933
]
Yonik Seeley commented on SOLR-1664:
SchemaField is final and very light weight for a reason - dynamic field
creation. All polymorphic behavior goes through the FieldType.
It's also the case that it can be safely published to other threads (so we
could easily have a cache of dynamic fields if it ever turned out to be a
significant cost).
Changing this design for the same of avoiding two string catenations during the
creation of a query really doesn't seem to make sense or meet the bar.
It also doesn't seem to make much sense to split polymorphic behavior between
FieldType and SchemaField. Existing code that used FieldType methods could be
getting the wrong implementation. What *could* make sense is having a
SchemaFieldFactory and a SchemaField, with all of the polymorphic behavior
encapsulated in SchemaField. The factory would just be responsible for
argument parsing and SchemaField creation (like our TokenFilterFactory today).
That's a relatively significant change though... not something we could
contemplate for 1.5?
Some Methods in FieldType actually should be in SchemaField
---
Key: SOLR-1664
URL: https://issues.apache.org/jira/browse/SOLR-1664
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Fix For: 1.5
Attachments: SOLR-1664.patch
The following methods are only overridable from FieldType.
{code:java}
public Field createField(SchemaField field, String externalVal, float boost) ;
protected Field.TermVector getFieldTermVec(SchemaField field,String
internalVal) ;
protected Field.Store getFieldStore(SchemaField field,String internalVal);
protected Field.Index getFieldIndex(SchemaField field,String internalVal);
public ValueSource getValueSource(SchemaField field, QParser parser);
public Query getRangeQuery(QParser parser, SchemaField field, String part1,
String part2, boolean minInclusive, boolean maxInclusive) ;
{code}
if there is anything specific to be done on a per-field basis it is not
possible. if we allow overriding SchemaField it will be more flexible.
I hope this can make it simpler to implement SOLR-1131
So ,there are two ways of overriding a functionality.
* Override Fieldtype#createSchemaField() and provide new implementation of
SchemaField
* Override methods from FieldType itself(if the behavior is not per field )
as it is now
SchemaField is made non-final and Solr only invokes methods on SchemaField
and not FieldType directly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1664) Some Methods in FieldType actually should be in SchemaField
[
https://issues.apache.org/jira/browse/SOLR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791935#action_12791935
]
Noble Paul commented on SOLR-1664:
--
bq.It's also the case that it can be safely published to other threads (so we
could easily have a cache of dynamic fields if it ever turned out to be a
significant cost).
I guess you are saying SchemaField should be immutable. I agree with that. As
long as any other implementation is immutable it should be just fine.
Some Methods in FieldType actually should be in SchemaField
---
Key: SOLR-1664
URL: https://issues.apache.org/jira/browse/SOLR-1664
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Fix For: 1.5
Attachments: SOLR-1664.patch
The following methods are only overridable from FieldType.
{code:java}
public Field createField(SchemaField field, String externalVal, float boost) ;
protected Field.TermVector getFieldTermVec(SchemaField field,String
internalVal) ;
protected Field.Store getFieldStore(SchemaField field,String internalVal);
protected Field.Index getFieldIndex(SchemaField field,String internalVal);
public ValueSource getValueSource(SchemaField field, QParser parser);
public Query getRangeQuery(QParser parser, SchemaField field, String part1,
String part2, boolean minInclusive, boolean maxInclusive) ;
{code}
if there is anything specific to be done on a per-field basis it is not
possible. if we allow overriding SchemaField it will be more flexible.
I hope this can make it simpler to implement SOLR-1131
So ,there are two ways of overriding a functionality.
* Override Fieldtype#createSchemaField() and provide new implementation of
SchemaField
* Override methods from FieldType itself(if the behavior is not per field )
as it is now
SchemaField is made non-final and Solr only invokes methods on SchemaField
and not FieldType directly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1664) Some Methods in FieldType actually should be in SchemaField
[
https://issues.apache.org/jira/browse/SOLR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791937#action_12791937
]
Grant Ingersoll commented on SOLR-1664:
---
bq. Changing this design for the same of avoiding two string catenations during
the creation of a query really doesn't seem to make sense or meet the bar.
These catenations are created during indexing. I'm about to put up a patch
that uses a StringBuilder instead and does more work outside of the loop.
Some Methods in FieldType actually should be in SchemaField
---
Key: SOLR-1664
URL: https://issues.apache.org/jira/browse/SOLR-1664
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Fix For: 1.5
Attachments: SOLR-1664.patch
The following methods are only overridable from FieldType.
{code:java}
public Field createField(SchemaField field, String externalVal, float boost) ;
protected Field.TermVector getFieldTermVec(SchemaField field,String
internalVal) ;
protected Field.Store getFieldStore(SchemaField field,String internalVal);
protected Field.Index getFieldIndex(SchemaField field,String internalVal);
public ValueSource getValueSource(SchemaField field, QParser parser);
public Query getRangeQuery(QParser parser, SchemaField field, String part1,
String part2, boolean minInclusive, boolean maxInclusive) ;
{code}
if there is anything specific to be done on a per-field basis it is not
possible. if we allow overriding SchemaField it will be more flexible.
I hope this can make it simpler to implement SOLR-1131
So ,there are two ways of overriding a functionality.
* Override Fieldtype#createSchemaField() and provide new implementation of
SchemaField
* Override methods from FieldType itself(if the behavior is not per field )
as it is now
SchemaField is made non-final and Solr only invokes methods on SchemaField
and not FieldType directly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1664) Some Methods in FieldType actually should be in SchemaField
[
https://issues.apache.org/jira/browse/SOLR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791942#action_12791942
]
Yonik Seeley commented on SOLR-1664:
bq. I agree with that. As long as any other implementation is immutable it
should be just fine.
Right, but this isn't about SchemaField being final or non-final, as it only
makes sense to make it non-final if you change a bunch of other stuff. This is
about changing the design of FieldType and SchemaField, and it's too big of a
change for 1.5, right?
Some Methods in FieldType actually should be in SchemaField
---
Key: SOLR-1664
URL: https://issues.apache.org/jira/browse/SOLR-1664
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Fix For: 1.5
Attachments: SOLR-1664.patch
The following methods are only overridable from FieldType.
{code:java}
public Field createField(SchemaField field, String externalVal, float boost) ;
protected Field.TermVector getFieldTermVec(SchemaField field,String
internalVal) ;
protected Field.Store getFieldStore(SchemaField field,String internalVal);
protected Field.Index getFieldIndex(SchemaField field,String internalVal);
public ValueSource getValueSource(SchemaField field, QParser parser);
public Query getRangeQuery(QParser parser, SchemaField field, String part1,
String part2, boolean minInclusive, boolean maxInclusive) ;
{code}
if there is anything specific to be done on a per-field basis it is not
possible. if we allow overriding SchemaField it will be more flexible.
I hope this can make it simpler to implement SOLR-1131
So ,there are two ways of overriding a functionality.
* Override Fieldtype#createSchemaField() and provide new implementation of
SchemaField
* Override methods from FieldType itself(if the behavior is not per field )
as it is now
SchemaField is made non-final and Solr only invokes methods on SchemaField
and not FieldType directly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1664) Some Methods in FieldType actually should be in SchemaField
[
https://issues.apache.org/jira/browse/SOLR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791946#action_12791946
]
Noble Paul commented on SOLR-1664:
--
bq.it only makes sense to make it non-final if you change a bunch of other
stuff.
Yes. So if some FieldType needs to change the behavior (such as createField,
getFieldQuery) on a per-field basis ,there is no straight way to do it. So far
there haven't been any. But SOLR-1131 opens the door for more such usecasee. if
we don't do it now , it may come up later.
bq.This is about changing the design of FieldType and SchemaField, and it's too
big of a change for 1.5, right?
It did not make any non-backcompat changes other than making some public
methods protected . So I am not sure if it qualifies as too big a change.
Some Methods in FieldType actually should be in SchemaField
---
Key: SOLR-1664
URL: https://issues.apache.org/jira/browse/SOLR-1664
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Fix For: 1.5
Attachments: SOLR-1664.patch
The following methods are only overridable from FieldType.
{code:java}
public Field createField(SchemaField field, String externalVal, float boost) ;
protected Field.TermVector getFieldTermVec(SchemaField field,String
internalVal) ;
protected Field.Store getFieldStore(SchemaField field,String internalVal);
protected Field.Index getFieldIndex(SchemaField field,String internalVal);
public ValueSource getValueSource(SchemaField field, QParser parser);
public Query getRangeQuery(QParser parser, SchemaField field, String part1,
String part2, boolean minInclusive, boolean maxInclusive) ;
{code}
if there is anything specific to be done on a per-field basis it is not
possible. if we allow overriding SchemaField it will be more flexible.
I hope this can make it simpler to implement SOLR-1131
So ,there are two ways of overriding a functionality.
* Override Fieldtype#createSchemaField() and provide new implementation of
SchemaField
* Override methods from FieldType itself(if the behavior is not per field )
as it is now
SchemaField is made non-final and Solr only invokes methods on SchemaField
and not FieldType directly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1664) Some Methods in FieldType actually should be in SchemaField
[
https://issues.apache.org/jira/browse/SOLR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792041#action_12792041
]
Yonik Seeley commented on SOLR-1664:
bq. It did not make any non-backcompat changes other than making some public
methods protected . So I am not sure if it qualifies as too big a change.
If a SchemaField changes the behavior (via subclassing) then everything must go
through SchemaField and not FieldType. That's a sizeable change.
Some Methods in FieldType actually should be in SchemaField
---
Key: SOLR-1664
URL: https://issues.apache.org/jira/browse/SOLR-1664
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Fix For: 1.5
Attachments: SOLR-1664.patch
The following methods are only overridable from FieldType.
{code:java}
public Field createField(SchemaField field, String externalVal, float boost) ;
protected Field.TermVector getFieldTermVec(SchemaField field,String
internalVal) ;
protected Field.Store getFieldStore(SchemaField field,String internalVal);
protected Field.Index getFieldIndex(SchemaField field,String internalVal);
public ValueSource getValueSource(SchemaField field, QParser parser);
public Query getRangeQuery(QParser parser, SchemaField field, String part1,
String part2, boolean minInclusive, boolean maxInclusive) ;
{code}
if there is anything specific to be done on a per-field basis it is not
possible. if we allow overriding SchemaField it will be more flexible.
I hope this can make it simpler to implement SOLR-1131
So ,there are two ways of overriding a functionality.
* Override Fieldtype#createSchemaField() and provide new implementation of
SchemaField
* Override methods from FieldType itself(if the behavior is not per field )
as it is now
SchemaField is made non-final and Solr only invokes methods on SchemaField
and not FieldType directly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1664) Some Methods in FieldType actually should be in SchemaField
[
https://issues.apache.org/jira/browse/SOLR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792347#action_12792347
]
Noble Paul commented on SOLR-1664:
--
bq.Then everything must go through SchemaField and not FieldType. That's a
sizeable change.
yes, But for all the existing components that arrangement can continue to work
(by keeping the methods public, though it is not recommended ) . Only the new
components which override SchemaField will have problem.
The point is , if we wish to go down this path , this is the best opportunity
to do that because, SOLR-1131 is introducing wholesale changes to the FieldType
API and this can be baked into the API together.
Some Methods in FieldType actually should be in SchemaField
---
Key: SOLR-1664
URL: https://issues.apache.org/jira/browse/SOLR-1664
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Fix For: 1.5
Attachments: SOLR-1664.patch
The following methods are only overridable from FieldType.
{code:java}
public Field createField(SchemaField field, String externalVal, float boost) ;
protected Field.TermVector getFieldTermVec(SchemaField field,String
internalVal) ;
protected Field.Store getFieldStore(SchemaField field,String internalVal);
protected Field.Index getFieldIndex(SchemaField field,String internalVal);
public ValueSource getValueSource(SchemaField field, QParser parser);
public Query getRangeQuery(QParser parser, SchemaField field, String part1,
String part2, boolean minInclusive, boolean maxInclusive) ;
{code}
if there is anything specific to be done on a per-field basis it is not
possible. if we allow overriding SchemaField it will be more flexible.
I hope this can make it simpler to implement SOLR-1131
So ,there are two ways of overriding a functionality.
* Override Fieldtype#createSchemaField() and provide new implementation of
SchemaField
* Override methods from FieldType itself(if the behavior is not per field )
as it is now
SchemaField is made non-final and Solr only invokes methods on SchemaField
and not FieldType directly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
