lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörn Franke <>
Subject Re: Feature: Solr implicitly defined field types?
Date Sat, 29 Dec 2018 09:14:29 GMT
I think it is a good idea, but I see some potential complexity for “deployment” of collections.
For instance, in environments where Solr is used as a shared platform amongst several stakeholders,
every time you deploy/modify a collection you need to take care that the platform types exist.
If it exists in the Test environment then i need to make sure that it exists as well in acceptance/production.
The problem is that the platform type could have been defined by somebody else who has not
yet (eg due to project/sprint delays) not updated the other environments. Another issue is
if I move to another Solr cluster in the same environment. Then, I have to make sure that
all platform types move with me. 

A (minor) issue is that platform types may change (for whatever reasons) and that then potentially
all collections have to be reindexed or we have different versions of the same platform type
making things not easier.

Currently we have all our Schema definitions in a version management system (we use the Schema
API but the JSON requests are out there) so that projects can inspire from each other. Needless
to say, that careful type engineering requires also some documentation on technical design
and may be indeed very Collection specific.

Another issue could be that a platform type may also imply a certain platform solrconfig.xml
(eg lib directive etc). 

I am not sure yet what are the exact benefits of referring to types of other collections in
the Solr runtime itself instead of having a version system and letting projects decide if
they want to adapt types of other collections, but maybe I am overlooking something here.

> Am 28.12.2018 um 17:36 schrieb David Smiley <>:
> While working on it occurred to me that
it would be nice if Solr had implicitly defined field types.  This would allow you to define
a field in your schema that refers to a type that is not also in your schema -- at least not
explicitly (need not explicitly be put in your schema.xml if classic, or need not be passed
to schema manipulation API if you use that).  The idea would be that these types would be
Solr platform provided field types that need not be defined by you.  
> There are multiple ways this loose idea might be conceived / imagined into a concrete
> (A) The main idea I'm kicking around right now is that Solr would _not_ throw an error
at the moment of reading your field definition that it doesn't see your type... instead it
would see it's a platform type (via some built-in hard-coded registry) and then register that
type on the fly.  So if you were to read the schema then you'd see it.  In this way, it's
kind of a shortcut.  Platform field types that you don't actually refer to will never end
up being put into your schema.
> (B) A schema could pre-initialize with the platform/implicit types.  This is the simplest
idea but I don't like it because you may not even need some of these types.  I'm not going
to go down this path now but wanted to mention it.
> I'm exploring (A) right now... I'm hoping to do this for at least a "_nest_path_"  field
in support of nested documents in 8.0, but conceivably the idea would be expanded to lots
of things in our base schema right now (int, str, etc.)
> -- 
> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> LinkedIn: | Book:

View raw message