SOLR-14726: Initial draft of a new quickstart guide #2594
Conversation
| A single document can be indexed as: | ||
| [source,subs="verbatim,attributes+"] | ||
| ---- | ||
| $ curl --request POST \ |
There was a problem hiding this comment.
A nit pick is that the collection is tech productions, and we have books..... Maybe we should think (separately) renaming techproducts to just products.
There was a problem hiding this comment.
Yes, good idea. I just took those docs off the Solr tutorial (which indexes books into techproducts). But, clearly, it is time for a better example.
| ---- | ||
|
|
||
| == Commit | ||
| After documents are indexed into a collection, they are not immediately available for searching. In order to have them searchable, a commit operation (also called `refresh` in other search engines like OpenSearch etc.) is needed. Commits can be scheduled at periodic intervals using auto-commits as follows. |
There was a problem hiding this comment.
i don't know if introducing terms used by other search engines is useful... though maybe we want to build up a gloassary that would list "equivalent" terms from other engines?
There was a problem hiding this comment.
A glossary sounds like a very good idea, for people coming from different systems.
There was a problem hiding this comment.
i don't know if introducing terms used by other search engines is useful
I feel that those coming from ES / OpenSearch backgrounds might be able to relate better. My main motivation with this document is to cut down on paragraphs of text and have more copy-paste-able snippets, esp. using JSON/V2 apis, to make Solr more appealing to those who find ES easy to use (mainly due to their superior beginner documentation).
There was a problem hiding this comment.
Makes sense to me as a point of reference. It might be more economical to say "(also called refresh in ElasticSearch/OpenSearch)" ... unless there are other search engines that refer to this concept as "refresh"?
| "create": { | ||
| "name": "techproducts", | ||
| "numShards": 1, | ||
| "replicationFactor": 1 |
There was a problem hiding this comment.
why no config attribute ?
There was a problem hiding this comment.
I thought the same. If the consensus is that we're going away from field guessing, then we should not promote the current _default config, but rather be explicit and reference the bundled techproducts configset. Or better, show them how to use Schema Designer to setup a configset for a certain dataset?
There was a problem hiding this comment.
For quickstart examples, we don't need the user to use their own configsets. They can start with the default configset, add fields (schema API) and their indexing/searching.
If the consensus is that we're going away from field guessing, then we should not promote the current _default config, but rather be explicit and reference the bundled techproducts configset.
I'm more inclined to remove the techproducts configset. They can be downloaded from some web resource for those who need it.
Or better, show them how to use Schema Designer to setup a configset for a certain dataset?
+1
A new quickstart guide that can potentially replace (or live side by side with) the Solr tutorial.
This is WIP at the moment, but would appreciate early feedback and thoughts.