Solr Cell

[Yonik Seeley <yo...@lucidimagination.com>]

Finally getting around to reviewing Solr Cell

ext.ignore.und.fl looks like it defaults to "true" instead of "false"
as specified on the Wiki, so metadata is ignored if not defined in the
schema.

Perhaps we should define common metadata fields in the example schema
for a better OOTB experience?

There should probably be a better way to catch stray attributes...
perhaps a way to specify a dynamic field, so if attribute "foo" is
encountered, and it's not defined in the schema, it will be mapped to
attr_foo.

naming:
 -  "fl" originally stood for "field list" in Solr, yet I see it being
used for single fields?
 -  do we really need to proceed all param names with "ext."?  seems
like it would be nice to actually use the same params when applicable
- for example, both csv and cell could use "literal.myfield=myval".

Thoughts?

-Yonik
http://www.lucidimagination.com

Re: Solr Cell

[Yonik Seeley <yo...@lucidimagination.com>]

On Fri, Jun 26, 2009 at 8:17 PM, Erik Hatcher<er...@ehatchersolutions.com> wrote:
> Seems like just a dynamic "*" mapping would suffice in this case, but
> dynamic field pattern would be fine with me too.

Using "*" removes the ability to detect field-naming errors.
We should be able to allow both.

>> naming:
>> -  "fl" originally stood for "field list" in Solr, yet I see it being
>> used for single fields?
>> -  do we really need to proceed all param names with "ext."?
>
> Yeah, I've commented on the ext.ens.ive parameter names before too.  It's
> not pretty to have to flatten a set of parameters into a single namespace
> though.  hl.*, facet.*, v.* (for VelocityResponseWriter) etc.  But...

response writers and search components need to coexist with eachother
and it can be nice to both avoid collisions and tell at a glance what
component a parameter is targeted at... but it doesn't seem
particularly necessary for update handlers.

-Yonik
http://www.lucidimagination.com

Re: Solr Cell

[Erik Hatcher <er...@ehatchersolutions.com>]

On Jun 26, 2009, at 6:49 PM, Yonik Seeley wrote:
> ext.ignore.und.fl looks like it defaults to "true" instead of "false"
> as specified on the Wiki, so metadata is ignored if not defined in the
> schema.
>
> Perhaps we should define common metadata fields in the example schema
> for a better OOTB experience?

+1 (but this lends itself to separate focused examples rather than a  
kitchen sink one)

> There should probably be a better way to catch stray attributes...
> perhaps a way to specify a dynamic field, so if attribute "foo" is
> encountered, and it's not defined in the schema, it will be mapped to
> attr_foo.

Seems like just a dynamic "*" mapping would suffice in this case, but  
dynamic field pattern would be fine with me too.

> naming:
> -  "fl" originally stood for "field list" in Solr, yet I see it being
> used for single fields?
> -  do we really need to proceed all param names with "ext."?

Yeah, I've commented on the ext.ens.ive parameter names before too.   
It's not pretty to have to flatten a set of parameters into a single  
namespace though.  hl.*, facet.*, v.* (for VelocityResponseWriter)  
etc.  But...

>  seems
> like it would be nice to actually use the same params when applicable
> - for example, both csv and cell could use "literal.myfield=myval".

...yeah, sharing these kinds of things across update handlers would be  
nice.

> Thoughts?

More than time allows to type them out :)

> -Yonik
> http://www.lucidimagination.com


	Erik

Re: Solr Cell

[Yonik Seeley <yo...@lucidimagination.com>]

On Fri, Jun 26, 2009 at 6:49 PM, Yonik Seeley<yo...@lucidimagination.com> wrote:
> Finally getting around to reviewing Solr Cell
>
> ext.ignore.und.fl looks like it defaults to "true" instead of "false"

Ah... it was actually defined as a default in the request handler....

Anyway, I returned some of this discussion to
https://issues.apache.org/jira/browse/SOLR-284
(284... wow has this issue been on the burner for a while ;-)

-Yonik
http://www.lucidimagination.com