This content has been marked as final. Show 5 replies
Would it be too onerous to return back all of the representative records (Np=2 or setNavERecsPerAggrERec(ALL_ERECS_PER_AGGR)?
Then possibly you could just iterate through all of the representative records in java and show the minimum price that way?
Hi Dev,1 person found this helpful
You should also consider the performance hit when you try to get all records for every Aggregated record for just displaying price.
You can use DERIVED_PROP element's with functions like MIN, MAX on price attribute and use this attribute for display. It will return MIN price.
Edit Derived_props.xml in notepad and add below snippet,
*<DERIVED_PROP FCN="MIN" NAME="priceDerived"*
Edited by: Pravin Chikhale on Sep 16, 2012 12:17 PM
If this is a regular retail app, is it so you can display a "from £xxxx" label? If so, then Pravin's suggestion is spot on - derived properties. One caveat is that derived properties will calculate the min value from the current data. This is important to remember, as if the customer contracts out some records through dimension value choices (e.g. size), the derived property will be derived from remaining records (e.g. all of the selected size). This is usually preferred behaviour, but I've had some customers want this label to be across all skus - the only way to do that is to pre-process your data to tag each sku with a "minimum price" attribute.1 person found this helpful
And avoid returning all records with an aggregated request - the Endeca impact isn't too bad, but you will absolutely kill the network if you've got a lot of skus per product.
It looks like I need to deal with lot other things if i go for Derived Props , bcz i also have Facet on price ranges where i cannot map the derived price to it...
So it looks like i need to tag my source data records to identify which is the least priced sku row for product and make sure only that row is returned when user queries. This seems to be solving the problem 100% , but there is little more effort involved in tagging my source records.
I will be jumping onto that section probably.
Thanks for your thoughts on this query.
Dimensions etc. all work correctly with aggregated records, derived properties are only for returning additional data with a representative record. You do not want to programmatically exclude all but the lowest price sku for a product, as this will mean customers can't dynamically navigate at a sku level. If you consider how skus are typically represented, i.e. colours and sizes for a product, with potentially different prices for each permutation of colour and size, then using aggregated records allows you to support granular search and navigation and display accurate price information based on the actual skus returned for the search (as opposed to just the overall product).