I'm glad to hear at least *somebody* other than me likes the idea :-)
I started some manual experimentation with it. After I got past one little
bug, sure enough it worked and would show up in the admin screen. It
showed up because of the /admin/luke handler interacting with IndexSchema,
*not*
I'd really like to see these implicit types.
Whether they are defined in code, in a implicit-types.xml in webapp is just
implementation. Also, a would just be necessary if there
is ever a need to take more explicit control, but if the right defaults are
established, I see only positive effects
Hmmm. My opinion is neutral on a . It would have
more implementation & documentation complexity to it IMO than an implicit
primitive type as I've been pushing. But still; it's alright.
Since I can't seem to convince anyone on the merits of implicit field
types, I will back out this part of
In some other thread or Jira that I cannot find now I proposed a new tag in
schema to make this explicit. So instead of 50 tags defining all primitive
types and dynamicFields, we could have one tag:
This is just a draft idea. This would give a way to disable these implicit
primitive types if
You would see these types in the HTTP schema API, and thus you would also
end up seeing it on the admin schema screen (which uses that API).
It would not be saved back to the XML file unless you're further
manipulating your schema via the HTTP schema API (managed schema). I ought
to verify all
To my mind the only types (or fields) that should get built-in are the ones
that would break solr if they were changed. Anything else should show up in
the config file. Your _nest_path_ probably falls into the "it would break
solr if it changed" category.
I notice in your initial post you say "So
On Fri, Jan 4, 2019 at 12:51 PM Shawn Heisey wrote:
> Looking at what came before, my preference would have been implicitly
> defined default types -- things like int, string, etc, defined in code.
> The only problem with that comes at Solr upgrade time ... what if we
> decide for a later
I'm jumping into this conversation a little bit late. Sorry for any
problems that causes.
On 1/4/2019 9:52 AM, Alexandre Rafalovitch wrote:
What about if a system schema was loaded at a startup implicitly.
Then, if a new schema is loaded and type definition is missing, it is
copied - at that
What about if a system schema was loaded at a startup implicitly.
Then, if a new schema is loaded and type definition is missing, it is
copied - at that time - into the specific schema. So, on the first
rewrite those - and only those used - types will be written out.
This allows to version the
I'm thinking this feature would be used conservatively -- and thus just
primitive types that wouldn't have an interesting configuration to them, or
for something you are really not expected to change (the nest path of
nested docs). So you wouldn't feel you had to go read the docs. The
schema
I'm perhaps slightly conservative with respect to configuration, but I'm
not fond of hidden configuration that I can't see. What I don't like is
looking at a config file and not seeing the full story. That means i have
to read the config and ALSO go read some part of the documentation that
I've
Broadly, you refer to "locale" issues. Solr's way of dealing with this
today is with optional & configurable use of URPs. The schema-less /
data-driven mode has some of these enabled; you can see it in the
solrconfig.xml including many date formats. You can look into that for
further info if
Hi David,
I now get the idea and yes this makes sense. It would require though some
tutorial or best practices, eg overriding a platform data type may make not so
much sense - it may confuse new developers in an existing project that know
Solr, but then get a platform type that has not the
Thanks for your thoughtful response Jörn!
...
On Sat, Dec 29, 2018 at 4:14 AM Jörn Franke wrote:
> 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
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
While working on https://issues.apache.org/jira/browse/SOLR-12768 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
16 matches
Mail list logo
