Everything that @Hishaam said is correct, but I want to clarify the 2 questions here:
So if I fast query an item with 100 children will all those come in to memory without paging or caching?
No - if you fast query a single item, you will get a single item. If your fast query adds children or all descendants you will get what you asked for. This is the ...
Based on previous projects, when using Where(x => x[fieldName] != null), the fieldName should match the one from the Solr Index. From your question, if you pass Where(x => x["shape_s"] != null), it should work.
Since you have dynamic fields being passed to the search context, you will need to get the field type. You can get it by using
Sitecore can be configured to do rebuilds with very different strategies depending on the architecture and requirements (it can be after publish, or full republish, or even manual, i.e. only rebuilt when manually triggered). I recommend reading this article: https://doc.sitecore.net/sitecore_experience_platform/setting_up_and_maintaining/search_and_indexing/...
When using Sitecore Fast Query, the result will not be cached. Sitecore has different layer of caching
So if I fast query an item with 100 children will all those come in to
memory without paging or caching?
If you use fast query, it will bypass all those levels of cache and hit the database directly because Sitecore Fast Query converts all the query ...
After working through this issue with sitecore support, it was determined that it was the documentOptions line that was the issue:
<documentOptions type="Sitecore.ContentSearch.SolrProvider.SolrDocumentBuilderOptions, Sitecore.ContentSearch.SolrProvider"...
The obvious answer is to use the Web index for any (site) search related functionalities.
There are also other site search like functionalities. You could think of a news articles or product (,or any other) overview, especially if you're including some kind of filtering mechanism.
Other then that the index could be used for any functionality that require ...
Your index needs to be configured in the indexes node. Probably that is done on CM but not on CD.
Check the config on CD for something like:
<configuration type="Sitecore.ContentSearch.ContentSearchConfiguration, Sitecore.ContentSearch">
<index id="your-index-name" type=".."&...
From the Solr source it looks like the connection to Solr is closing before Solr can read the query fully.
This might happen if you have particularly large queries as there are some limits that apply to the size of request headers in a lot of circumstances. Solr also generally imposes a 1024 clause limit on queries, but this is tunable.
Set your Search ...
You dont need to disable lucene indexes as this can be done from web config search app setting.
This might come from one of your custom index configurations, try to remove the custom solr index configs one by one and see which one is causing the issue.
One of your custom indexes uses a solr core that is not yet created locally.
You might ...
Have you tried sitecore support?
Do you have a patched crawler?
There are a couple of bugs I've encountered which result in duplicate items in the web database. Which require patches from support.
One bug only shows itself when using ContentSearch.Indexing.DisableDatabaseCaches=true
The other shows itself when you unpublish a version of an item. And you ...
Sitecore indexes are built by using following methods
Publishing the content
Navigate to control panel -> Indexing Manager -> clicking on
rebuild search index button with the required indexes.
Rebuild indexes by using Rebuild method of API
You can check to see if following ...