Hi,

it seems from my limited experience thus far that as new data types are
added, schema.xml will tend to become bloated with many different field and
fieldtype definitions.  Is this a problem in real life, and if so, what
strategies are used to address it?

FredZ

On Oct 23, 2011, at 19:34 , Fred Zimmerman wrote:
> it seems from my limited experience thus far that as new data types are
> added, schema.xml will tend to become bloated with many different field and
> fieldtype definitions.  Is this a problem in real life, and if so, what
> strategies are used to address it?

... by keeping your schema lean and clean, only with what YOU need in it.  Granted, I'd personally keep all the built-in Solr primitive field types defined even if I didn't use them, but there aren't very many and don't really clutter things up.

Defined fields should ONLY be what you need for your application, and generally that should be a tractable (and necessary) reasonably sized set.

Erik
 

So, basically, yes, it is a real problem and there is no designed solution?
 e.g. optional sub-schema files that can be turned off and on?

On Sun, Oct 23, 2011 at 6:38 PM, Erik Hatcher <[EMAIL PROTECTED]>wrote:

>
> On Oct 23, 2011, at 19:34 , Fred Zimmerman wrote:
> > it seems from my limited experience thus far that as new data types are
> > added, schema.xml will tend to become bloated with many different field
> and
> > fieldtype definitions.  Is this a problem in real life, and if so, what
> > strategies are used to address it?
>
> ... by keeping your schema lean and clean, only with what YOU need in it.
>  Granted, I'd personally keep all the built-in Solr primitive field types
> defined even if I didn't use them, but there aren't very many and don't
> really clutter things up.
>
> Defined fields should ONLY be what you need for your application, and
> generally that should be a tractable (and necessary) reasonably sized set.
>
>        Erik
>

On Oct 23, 2011, at 20:23 , Fred Zimmerman wrote:

> So, basically, yes, it is a real problem and there is no designed solution?

Hmmm.... problem?  Not terribly so, is it?  

Certainly I'm more for a de-XMLification of configuration myself though.  And we probably should bake-in all the basic field types so they aren't explicitly declared (but could still be overridden if desired).

> e.g. optional sub-schema files that can be turned off and on?

Hmmm... you can use XInclude stuff.  Not sure that gives you the "optional" part of things exactly, but there is also the ${sys.prop.name[:default_value]} syntax that can be used in the configuration to pull off conditional types of tricks in some cases.

Right, so no designed solution to the problem, I suppose.  It's what it is at this point.

I'm curious to hear more elaboration on the specifics of how this is a problem though.  Certainly there is much room for improvement in most things.  

Erik

>
> On Sun, Oct 23, 2011 at 6:38 PM, Erik Hatcher <[EMAIL PROTECTED]>wrote:
>
>>
>> On Oct 23, 2011, at 19:34 , Fred Zimmerman wrote:
>>> it seems from my limited experience thus far that as new data types are
>>> added, schema.xml will tend to become bloated with many different field
>> and
>>> fieldtype definitions.  Is this a problem in real life, and if so, what
>>> strategies are used to address it?
>>
>> ... by keeping your schema lean and clean, only with what YOU need in it.
>> Granted, I'd personally keep all the built-in Solr primitive field types
>> defined even if I didn't use them, but there aren't very many and don't
>> really clutter things up.
>>
>> Defined fields should ONLY be what you need for your application, and
>> generally that should be a tractable (and necessary) reasonably sized set.
>>
>>       Erik
>>