I am using Contentful to fetch some data for my website.
I have a productId field in Contentful for each entry which is of type Short text, list field. This field accepts product ids as comma-separated values.
ID1234,ID2343, ID2344, .......
But this seems to be limited to 1000 IDs.
Is there a way by which I can add up to 100k IDs? By using some other types than using Short text, list field or by upgrading the Contentful account.
Contentful DevRel here. 👋
I think this is a hard limit on all pricing tiers.
What you could do is to use the JSON field instead. If the editors are not tech-savvy JSON is obviously not the best choice. In that case you could use the App Framework and put some custom UI on top of the JSON field.
Related
I have used solr search engine which has a feature of dynamic fields. For example , if we define product_* field in the schema.xml, it will accept all the fields starting with product_ during the indexing.
Is there a feature like this in azure search where we can just define a wildcard for a field and it can accept the related fields in the indexing? As the fixed field thing reduces flexibility and one has to define a new schema every time for adding new fields.
Azure Cognitive Search does not support dynamic fields. Adding fields to the schema as you detect them during indexing is the suggested workaround.
Please consider creating an item on our User Voice page for this. While we haven't considered adding support for dynamic fields specifically, we have been looking at making schemas more flexible and extensible, and your input could help us prioritize this.
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'm trying to speed up my ssp application by using nlapiLookupField where possible instead of having to load the whole record and it's sublists using nlapiLoadRecord. Unfortunately it doesn't seem to work with lineitem fields. Is there an api call to fetch a line item's value with out the needing to use nlapiLoadRecord?
I'm using 1.0 as dictated by SCA.
nlapiLookupField() is limited to body fields, however you can use other search apis (eg: nlapiSearchRecord()) to return any information that a saved search can access, which obviously includes item lines. This is particularly useful if you want to read a few fields from a large number of records, but I believe it's performant compared to loading a record even if you just return a single result, say by passing in an internal id as one of the filters. I haven't tested to compare a single result search with a single record load though, so YMMV.
Unfortunately, no. Only body fields are supported with nlapiLookupField or search.lookupFields.
I am using E-commerce module of Kentico portal and it has two fields for Products pricing : SKUPrice and SKURetailPrice.
I needed one more field to show sell price and I added a new field in Modules application of the portal.(Modules->E-Commerce->Classes->SKU->Fields->New Field)
Now, I need to access this field in my code,but SKUInfo class doesn't show me the newly added field.What I need to do so that the newly added field reflects in my project code ?
I have already build the entire solution multiple times.Any other solutions please.
You can use GetValue and SetValue methods for such fields like this:
SKUInfo sku = ...;
string a = sku.GetValue("field").ToString();
sku.SetValue("field", "value");
JanH has the answer for custom fields you set, also keep in mind though that there is a "SKUCustomData" for other information that you want to store. It takes a Name-Value pair dictionary if memory serves me correctly, and useful if you need to store configuration information or other things that won't be located on the normal SKU table.
We want to index few public e-commerce sites. When our customers search any one of the product the results, should display sort by pricing from all indexed e-commerce sites.
From My Understanding: The public e-commerce sites have different meta tag for pricing i cannot even consolidate into one meta tag.
Is there possible to Feed via XML, but don't have much idea inside how to achieve? we don't have db access to parse only required data
Via Entity recognition how i can able to index the price as a meta tag ?
Could u please advice us, whether it is achievable or not? If yes, which one is the best solution and refer document for this.
Ignoring the sorting issue and just concentrating on normalising the price metadata problem. You need a way to read the price from whatever metadata field it's in and create a new metadata field with a common name and the same value.
There are a few ways to do this but the simplest are probably:
Generate a Meta-and-url feed for each document and add in the normalised metadata
Crawl via a proxy that can add a X-GSA-External-Metadata header in containing the normalised metadata