Access to all prices for sale in case of price inner record handling FIRST_OCCURENCE / SUM about evitadb HOT 5 CLOSED

@novoj I don't think we can do it similarly easy in REST as in GQL without introducing separate endpoint for prices. Because in REST we use standard priceContent constraints for fetching prices, the priceContent doesn't have such option.
I could either return all prices for sale automatically when PriceContentMode.ALL is requested, or we could introduce another PriceContentMode similar to RESPECTING_FILTER which would return the price for sale as well as the rest of prices for sale.

from evitadb.

I don't understand. If you use RESPECTING_FILTER in price content - you'll receive ALL PRICES FOR SALE in the returned entity. But as I study the implementation you'd get really all the prices that are participating in the calculation - we lack method that would return winning prices for sale for each inner record id. I'd have to add such method.

from evitadb.

So, we have new fields in GQL allPricesForSale and multiplePricesForSaleAvailable where the first one can take arguments to calculate custom prices besides the main query the same way priceForSale field does.
In REST, there is new multiplePricesForSaleAvailable property for entities that have price inner record handling FIRST_OCCURENCE or SUM.

from evitadb.

Reopening this issue because we need to rework the multiplePricesForSaleAvailable behaviour.

After some discussion we agreed on following behaviour:

• NONE:
  • always false - there isn't a scenario where NONE returns multiple prices for sale
• FIRST_OCCURENCE:
  • price for sale for only one innerRecordId -> false
  • prices for sale for multiple innerRecordIds that have different price values -> true
  • prices for sale for multiple innerRecordIds that all have the same price value -> false
• SUM:
  • price for sale for only one innerRecordId -> false
  • prices for sale for multiple innerRecordIds no matter the price values -> true

We need to somehow be able to tell if two prices for sale for different innerRecordIds have same value, but we have priceWithoutVat, priceWithVat and the vat. We've agreed to use the priceType for determining by which value to compare so that it is up to the client to specify it's use-case. So if priceType = WITH_VAT we will use the priceWithVat of each price to compare sameness, if priceType = WITHOUT_VAT we will use the priceWithoutVat of each price to compare sameness.

The same logic for comparing we will use for sorting the allPricesForSale array returned from GraphQL API (this is new as well), so that FEs can easily determine lowest and highest values.

from evitadb.

I've updated the computation - please push your changes as a fix so that we don't trigger next major version - only patch. Thanks.

from evitadb.