On Dec 24, 2009, at 12:42 PM, [EMAIL PROTECTED] wrote:

> Author: yonik
> Date: Thu Dec 24 17:42:48 2009
> New Revision: 893792
>
> URL: http://svn.apache.org/viewvc?rev=893792&view=rev
> Log:
> SOLR-1131: first pass at fixing support for subFieldSuffix (index + search)
>
> Modified:
>    lucene/solr/trunk/example/solr/conf/schema.xml
>    lucene/solr/trunk/src/java/org/apache/solr/schema/CoordinateFieldType.java
>    lucene/solr/trunk/src/java/org/apache/solr/schema/FieldType.java
>    lucene/solr/trunk/src/java/org/apache/solr/schema/PointType.java
>
> Modified: lucene/solr/trunk/example/solr/conf/schema.xml
> URL: http://svn.apache.org/viewvc/lucene/solr/trunk/example/solr/conf/schema.xml?rev=893792&r1=893791&r2=893792&view=diff
> =============================================================================> --- lucene/solr/trunk/example/solr/conf/schema.xml (original)
> +++ lucene/solr/trunk/example/solr/conf/schema.xml Thu Dec 24 17:42:48 2009
> @@ -407,7 +407,7 @@
>       The subFields are an implementation detail of the fieldType, and end
>       users normally should not need to know about them.
>      -->
> -    <fieldType name="location" class="solr.PointType" dimension="2" subFieldType="double"/>
> +    <fieldType name="location" class="solr.PointType" dimension="2" subFieldSuffix="_d"/>
>
>  </types>

Shouldn't we demo both?

>
>
> Modified: lucene/solr/trunk/src/java/org/apache/solr/schema/CoordinateFieldType.java
> URL: http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/schema/CoordinateFieldType.java?rev=893792&r1=893791&r2=893792&view=diff
> =============================================================================> --- lucene/solr/trunk/src/java/org/apache/solr/schema/CoordinateFieldType.java (original)
> +++ lucene/solr/trunk/src/java/org/apache/solr/schema/CoordinateFieldType.java Thu Dec 24 17:42:48 2009
> @@ -55,7 +55,7 @@
>   protected FieldType subType;
>   public static final String SUB_FIELD_SUFFIX = "subFieldSuffix";
>   public static final String SUB_FIELD_TYPE = "subFieldType";
> -  private String suffix;//need to keep this around between init and inform, since dynamic fields aren't created until before inform
> +  protected String suffix;
>   protected int dynFieldProps;
>
>   public int getDimension() {
> @@ -76,6 +76,7 @@
>     if (subFT != null) {
>       args.remove(SUB_FIELD_TYPE);
>       subType = schema.getFieldTypeByName(subFT.trim());
> +      suffix = POLY_FIELD_SEPARATOR + subType.typeName;      
>     } else if (subSuffix != null) {
>       args.remove(SUB_FIELD_SUFFIX);
>       suffix = subSuffix;
> @@ -90,18 +91,9 @@
>
>   public void inform(IndexSchema schema) {
>     //Can't do this until here b/c the Dynamic Fields are not initialized until here.
> -    if (suffix != null){
> -      SchemaField sf = schema.getField(suffix);
> -      subType = sf.getType();//this means it is already registered
> -      dynFieldProps = sf.getProperties();
> -    }
> -    else if (subType != null) {
> +    if (subType != null) {
>       SchemaField proto = registerPolyFieldDynamicPrototype(schema, subType);
>       dynFieldProps = proto.getProperties();
> -    } else {
> -      throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, "The field type: " + typeName
> -              + " must specify the " +
> -      SUB_FIELD_TYPE + " attribute or the " + SUB_FIELD_SUFFIX + " attribute.");
>     }
>   }
>
How does this handle the suffix piece?

On Thu, Dec 24, 2009 at 1:28 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
> On Dec 24, 2009, at 12:42 PM, [EMAIL PROTECTED] wrote:
>> -    <fieldType name="location" class="solr.PointType" dimension="2" subFieldType="double"/>
>> +    <fieldType name="location" class="solr.PointType" dimension="2" subFieldSuffix="_d"/>
>>
>>  </types>
>
> Shouldn't we demo both?

There are tradeoffs to including all variations of something (that
being schema bloat).  These two variants do the exact same thing for
the end user (since the only difference is sub-field naming), so we
should pick one or the other IMO.  That's what most people will end up
using.  We could include the other variant commented out, but I think
that's overkill too given that we listed an example of each in the
comment for "location".

-Yonik
http://www.lucidimagination.com

On Thu, Dec 24, 2009 at 3:21 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
> Any objection to moving the suffix/subfield stuff up to CoordinateFieldType?  I'm working on the Cartesian Tier stuff and it has much the same pattern for this stuff.

I dunno... will it complicate things more?  What's the difference
between CoordinateFieldType and PointFieldtype?
What will the base class be for asking for a bounding box?

-Yonik
http://www.lucidimagination.com

On Dec 24, 2009, at 3:33 PM, Yonik Seeley wrote:

> On Thu, Dec 24, 2009 at 3:21 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
>> Any objection to moving the suffix/subfield stuff up to CoordinateFieldType?  I'm working on the Cartesian Tier stuff and it has much the same pattern for this stuff.
>
> I dunno... will it complicate things more?  What's the difference
> between CoordinateFieldType and PointFieldtype?

I envision you could have things like a ShapeFieldType that inherits from CoordinateFieldType (i.e. has a subtype and a dimension)
> What will the base class be for asking for a bounding box?
>

Actually, what I think I need is the subType/suffix handling separate from the dimension stuff.  I'll put up a patch in a few days.  Time to go eat some Christmas cookies.

-Grant

On Dec 24, 2009, at 4:36 PM, Grant Ingersoll wrote:
>
>
>> What will the base class be for asking for a bounding box?
>>
>
> Actually, what I think I need is the subType/suffix handling separate from the dimension stuff.  I'll put up a patch in a few days.  Time to go eat some Christmas cookies.

See https://issues.apache.org/jira/browse/SOLR-1586 for my proposed refactoring.  Basically, I introduced a new base class for CoordinateFieldType that has the subtype/suffix handling, but not the dimension stuff, as the CartesianTierField only deals with lat/lon.