Currently i'm working with Microsoft Azure Search ( PaaS ) services for my product selector implementation.
I made research on azure search & thought of using collections concept but i'm stopped at multi-level hirerchy rendering.
Let me brief about my problem, we have aggregated product data ( meaning multiple aggregator of products ).
In our database having diffrent levels of products hirerchy like 2,3,4 and 8 levels ( taxonomy categorizstion ).
For example
Chocolate > Cream Chololates > Snickers Chocolate, 150 gm
Personal Care > Face Care > Face Wash > Family Facewash > Family Facewash Single Pack > HUL > Ponds > Men Fair & Clean FaceWash - 50 gms
Sports > Team Sports > Hockey > Sticks > Hockey Stick - 60 cm
Note: Last level is product & we don't know the how many levels product hirerchy limited to.
Problem Statement:
In Front End, on selection of datasource we have to call API to render in frontend.
Here, every datasource is independent of hirerchy levels. ( i.e first datasource may have 5 levels, second one may have 8 levels )
Now problem here is user may select any level by simply searching word ( like Facewash). in other way, top-bottom / bottom-top approach.
If i use the azure search collection approach then i'm not sure of result with reference to level ( i can find only product level ).
can someone suggest best approach to solve this issue ? Thanks in advance.
We don't have a built-in way to handle multi-level taxonomies yet, but you could try the following approach proposed by one of our users: Multi-level taxonomy facets in Azure Search. To render different taxonomies for different data source types, you could use filters. The following article explains how to use the Filter and Facet APIs together: How to implement faceted navigation in Azure Search.
Related
The current CRM UI allows you to create relatively complex queries which you can even extend further with tools like FetchXML Builder.
However, when we get to select the columns in the View layout, the interface provides access only to the first direct related set of entities and does not navigate further down.
There are many cases where the column you want to include in the View is just "two-clicks" away and you cannot include it because is "too far". To make things worse, the FetchXML Builder allows you to re-write the join but it does not allow you change the the columns layout you started with when you opened the View initially. IOW, you can modify the query logic but you cannot include additional columns as required.
One possible solution would be to edit the solution directly and inject the FetchXML directly (I have not tried this though) but I would like to listen to the community opinion first or to other possible solution.
Regards and thank you for taking your time.
Unfortunately this is a long existing limitation. There is no supported customization workaround to circumvent this other than building a Fetchxml report or Power BI report to embed with the necessary layout.
From documentation:
You can include columns from the current entity or any of the related entities that have a 1:N entity relationship with the current entity.
You can tweak the layoutxml of any view, but still it has to be in supported zone to avoid failures.
To test a restriction so that a product code was not visible on the front end site for apparel store (provided OOTB by Hybris), I made a restriction by going to BackOffice->Personalizatiopn and made a new personalization rule by giving the filter as :
{code} = '300392196'
And ApplyOn customerGroup
But still when I go to a site for my extension(mysitestorefront) like :
http://localhost:9001/mysitestorefront/?site=apparel-uk
I am able to search the product in "What You're looking for section".Am I doing some mistake in implementing the restriction?
Personalization apply to the direct flexible search query, but storefront search is based on Solr, it will make a query to Solr. All indexed products can be searched from the storefront. So if you restrict a product to be searched, then stop indexing it.
Which products should be indexed are defined by flexible search queries provided in full and update fields of your indexed type.
Go to HMC/BackOffice > System > Facet Search > Indexed Types > Select your indexed type > There you find full and update queries.
append your where clause (like where {code} != '300392196') to query and do full solr indexing
If you want to hide/show your product to the specific group based on some condition, then you can follow this steps
I'm trying to build a list using drupal6, views and node reference.
The list should be look like:
vehicle 1
feature 1
feature 2
feature 3
extra 1
vehicle 2
vehicle 3
The vehicle is a custom node-type, feature and extra also. In my view I'm listing all vehicle-node (as fields), added relationships to feature and extra nodes and added the reference-fields.
Now I'm getting the desired list. But when the displayed node contains more than one relationship of the same type (see feature in vehicle 1 in list above) I'm getting one result line per relationship (vehicle 1 get displayed three times).
Is there any way to group these results?
After some longish time searching and trying to implement custom theming solutions to combine the duplicated results, I found a similar question at drupal.org where i found some useful hints:
It seems to be an SQL-related issue (described here) not "solvable" with views2.
I'm now using the Reference view module (http://drupal.org/node/1319746) which allows to set up "child"-views (i.e. features and extras) I can include as fields in my original view (vehicles).
Searching Magento with fulltext search engine and like method , it will store results in catalogsearch_fulltext table in "data_index" field where it stores value in the format like
each searchable attribute is separated with |.
e.g
3003|Enabled|None||Product name|1.99|yellow|0
here it store sku,status,tax class, product name , price ,color etc etc
It stores all searchable attribute value.
Now the issue is for Configurable product , it will also store the associated products name ,price ,status in the same field like
3003|Enabled|Enabled|Enabled|Enabled|None|None|None|None|Product name|Product name|associted Product name1|associted Product name2|associted Product name3|1.99|2.00|2.99|3.99|yellow|black|yellow|green|0|0|0|0
So what happen is if i search for any word from associated product, it will also list the main configurable product as it has the word in its "data_index" field.
Need some suggestion how can i avoid associated products being included in data_index, So that i can have perfect search result.
thanks
We are looking into our search as well and it has been surprising to see the inefficiencies included in the fulltext table. We have some configurable products as well that have MANY variations and their population in the fulltext search is downright horrendous.
As for solutions, I can only offer my approach to fix the problem (not completed: but rather in the process).
I am extending Magento to include an event listener to the process of indexing the products (Because catalog search indexing is when the fulltext database is populated). Once that process occurs, I am writing my own module to remove duplicate entries from the associated products and also to add the functionality of adding additional search keyword terms as populated from a CSV file.
This should effectively increase search speed dramatically and also return more relevent search results. Because as of now, configurable products are getting "search bias" in the search results.
This isn't so much of an answer as a comment, but it was too lengthy to fit in the comments but I thought this might be beneficial to you. Once I get my module working, if you would like, I can possibly give you directions on how you could implement a similar module yourself.
Hope that helped (if only for moral support in magento's search struggle)
I've followed the topic 'Creating lists' in the Orchard Project docs but I'm struggling to think how best to implement my preferred sort order and direction in the resulting rendering of Summary display of the content items.
For example, if I create a Book Reviews list as in the example, and I then add a Published Date field following the topic 'Creating a custom field type' then how would I alter my theme or the views in the Module to display (and possibly also filter) the content items by that custom field.
The 'Creating lists' topic discusses how widgets can implement sorting and filtering, but not how the main content type can do so.
p.s. if you know the answer to this you're probably well on the way to being able to implement an Event Calendar Module as suggested by the Orchard Module Challenge; why not have a go and stand a chance to win a TV / XBox / KINECT!
Research to date:
I've noticed that ordering in a Container part is implemented using the following property
OrderByProperty
(Orchard.Core.Containers.Models.ContainerPartRecord)
In Orchard 1.4 you can Projection Module to achieve that.
In previous versions, I used LINQ queries to do the sorting on the custom field.