Developer forum

Hi Lars

You need to create a new custom field in your Repository index that is based on the field you want to use and set the custom field to "Un-analyzed" which means that field text strings will not be split into segments when a textstring contains several words

You can then use this custom field for your structured query instead of the actual field

Hope this helps you

Best regards Anett

Hi Lars,

This is because the underlying Index is "analyzing" the fields by default, which cause a string like "Cups and Plates" to be split into individual words.

You can either:

• Change the default behavior of the IndexBuilder to be NOT analyzed - but that introduces other issues
  
  OR
   
• Create a new index field that uses Lvl2 as the source, but set it to be NOT be analyzed - then use the new field in Structured Query
  This will ensure that "Cups and plates" is treated as a single string.

Best Regards,

Nuno Aguiar

Thanx.

Will se how it's best to handle this then.

The fields and their values are derived from NAV with integration, so...

/Lars

Hello Lars,

- it's not a problem if the field is derived from NAV with integration, check the attached printscreen.

Follow the advise from Anett, and you can go on weekend very soon ;-)

Br. Michael

Hello Lars,

- it's not a problem if the field is derived from NAV with integration, check the attached printscreen.

Follow the advise from Anett, and you can go on weekend very soon ;-)

Br. Michael

Other than i now have to spend hours setting up my own index builder. ;)
Just because as is,i  cannot change this one field in the Dynamcweb default  without setting up exceptions and renaming stuff for the end non technicha pim user to handle.
That is even more problematic, if they want to use other fields that contains similar composed values.
The same issue will occur on the webshop using these fields for filtering in the front-end

Whould have been much easier, if i could edit the default DW provides..

But thanx again for the input..

Hi Lars,

You can change the defaults here https://www.screencast.com/t/Zc0cf5ZKaH

But some of your query expressions (not Structured Queries) would not work as expected, because you would no longer be able to use "Contains" and "In" for most of the fields, because they would not be analyzed.

The issue becomes that you sometimes want the same field to be analyzed and sometimes you don't, so you really have to pick and default setting and then deal with the exceptions. A good example is the Product Name:

• You want it analyzed for:
  • Free text search - so you can find any "word" in the product name
• You don't want it analyzed for:
  • Sorting - you want to sort based on the full string

Hope that makes sense.

Nuno Aguiar

Hi agian

The easiest and most flexible option that we normally use is to keep your originak field from NAV as analyzed and create at new extra field by adding a new field directly to your product index in Repositories under Settings (add a field just below the product index builder area in the index)

Chose your original NAV field as the source for the new field and set your new field as unanalyzed

This way you do not have to settle with any choices. When you need normal search on the field you use your original field and when you need it to be unanalyzed you use your custom index field. You can name your new index field as eg lv2Unanalyzed or CustomLv2 in order to avoid any mistake in use. You do not have to use the new index field for other things if not needed or change any handling you currently have for the original field

Win-win 😊

You can find a technical note her about how to extend your index and create a new custom index field

https://doc.dynamicweb.com/documentation-9/pim/structure-workflows/structure-queries

Never mind this comment, the source index from the query was cleared for some reason; an error on missing index would have been a nice feature though :)

BR Ronni