What happens when "updating" a document, but only changing a retrievable field. Will the document be reindexed?
I'm trying to mesure the "cost" of updating a retrievable field to a lot of documents to decide if I should put this field on the index or getting from SQL Server after consulting the index.
Thanks in advance
MergeOrUpdate behavior is the same as Merge, if the document (document key specifically) already exists. It doesn't matter which are the properties of the field (retrievable, filterable, etc.). In other words, the whole document is not re-indexed, but the specified field values in the call are merged. For more information on the REST API behavior: Add, Update or Delete Documents (Azure Cognitive Search REST API).
Related
The data I have is of the form
{"event": {"custom": {"dimensions": [{"Id": ....}, {},...{}]}, ...},...}
The key that I need to index by is in the list. However, Cognitive Search does not seem to let me access the value within the list. Azure Cog. Search also fails to access any content from the list while trying to index.
Are there any solutions you can think?
Not sure how you're trying, but Azure Cognitive Search supports Complex types. Take a look in the following link:
https://learn.microsoft.com/en-us/azure/search/search-howto-complex-data-types
As an Alternative, you can project the internal dimensions (assuming they have a fixed number of dimensions) to fields in your index.
When using Indexers to import the data, key fields are limited to what can be expressed in a field mapping which has some support for mapping functions but wont allow you to select a value of an object in a collection. Your only options are to pre-process and transform the data (such as a query if this is coming from Cosmos DB, or azure function trigger if coming from blobs) or use a different field as the id and put the dimension id in another field that is queryable.
To make the data queryable you can use complex types or if the dimensions are always in the same ordinal you can use output field mappings to map it to a field by collection ordinal such as /document/event/custom/dimensions/1.
I have created Vehicle Table In the Ledger and added some vehicles in QLDB and I deleted the vehicle data.Now I am not able to fetch the metadata id because user table and committed table will have only non-deleted latest version of application data.So I am not able to fetch History of that deleted Data through metadata.Kindly help me with PartiQL query to fetch the History, if there is a way.
Note: I don't have vehicle registration table which stores metadataId of vehicles.
The way you are doing it is correct. First, you filter on history by some known attribute (in this case, a user defined primary key such as 'VIN') and you retrieve the document id. After that, you can filter history using that document id.
The second query should return the same as the first but it will also contain the deletion information (the first query will not include it because the deletion removes the attribute).
Note that the document id is returned as part of the DELETE PartiQL statement.
We need to query SharePoint for new and changed documents. The 'Write' property gives the modified timestamp from inside the document metadata (i.e. inside the document properties), not the time the document was added to SharePoint.
I've tried this query:
and(IsDocument:true, write:range(2018-02-16, max) )
but the write time is based on the date embedded inside the document (not the date the document was added to SharePoint).
Does anyone have any guidance they can share?
Update with more test results:
Digging into the properties, I think that the DiscoveredTime property might be what I'm looking for. This documentation (https://technet.microsoft.com/en-us/library/jj219630.aspx) says that the DiscoveredTime property isn't searchable, but I am able to search using this:
and(IsDocument:true, DiscoveredTime:range(2018-02-16, max) )
I can't find anywhere that explains what DiscoveredTime actually is, but it seems to correlate with when the document was added to SP.
I am using azure cosmos db for saving and editing my session information. Currently i am not using ID in my document, instead i have another unique field with all docs. How can i update my query to get documents?
You can use whatever property you want, for your custom key (just make sure you don't remove its index). By default, all properties are indexed unless you explicitly set up a custom index policy that removes certain properties from being indexed.
You cannot eliminate the built-in id property though; if you don't set it explicitly, it will just be set to a guid.
If you are doing queries, this really shouldn't matter, functionality-wise. Just search on whatever properties you want. However: If you are doing point-reads (a read is more efficient, RU-wise, than a query, when retrieving a single document) you can only perform a point-read by specifying the id property, not your custom property. If you must use a custom property and you need to do point-reads, you can consider storing your custom property as id as well (as long as it's guaranteed to be unique per document).
How the search everything kind of application is indexing & keeping track of data into its search indexes.
Recently I have been working on Apache Solr which is producing amazing results for a search. But it was for one particular products catalog section that is being searched. As Solr is a stores it's data document, we indexed searchable fields as document in solr. I'm not sure how it can be used to build a search everything kind of search? And how should I index data into Solr?
By search everything I mean, to search into different module for information like Customers, Services, Accounts, Orders, Catalog, Support Ticket, etc. So search return results which is combined as a result from a single search form and user don't need to go into different forms for search that module?
Do I need to build different indexes for each such data models or store them into solr as single document? What is the best strategy to implement this.
You can store all that data in a single index with each document having an extra field that stores its type (Customer, Order, etc.). For the within-module search, just restrict the search query to documents of that type. For the Search All functionality, use copyField to copy all the relevant fields in each document type into one big field, and search with the document type field unconstrained.