Ewald, Functional queries combines well with block join as well as query time join, here are examples for latter one http://blog-archive.griddynamics.com/2015/08/scoring-join-party-in-solr-53.html It must be the same for block join. What doesn't work exactly?
On Wed, Feb 1, 2017 at 1:39 PM, Ewald Moitzi <ewald.moi...@student.tugraz.at > wrote: > Hello, > > I am unsure if solr is the right solution for a problem > that we have, of if it is better to stick with a relational > database (and if it should be done in solr how to implement it). > The explanation is a bit lengthy, but please > bear with me. > > The problem: > Sort results of a vendor search for a product according to price > including delivery costs. > > The data: > The store itself is a marketplace, and each product can be > supplied by different vendors. The vendors can define delivery > costs for different price ranges. > E.g: > > _price from_| price to_| delivery cost | > | 0 | 49 | 10 | > vendor --| 50 | 99 | 5 | > | 100 | max | 0 | > > So, for product with a price of 55, I want the result to be 60. > > Additional requirements: > - The product price is also calculated, based on properties > of the vendor. > - There is also a pickup option, and there should be no > duplicate results. > - Different shipping costs for different countries. > > Progress so far: > My idea is to store each range as a subdocument for a vendor, but > I don't know how to construct a query for that. So far I have > managed to implement a simpler version that gives the right result for > each country using dynamic fields, but this uses only a free delivery > above x approach and that is not what we want. > > I have looked into the Block Join Query parser, but as far as I can > tell this does not allow to construct a function query with inputs > from parent and child documents. > > Why solr: > - sort and limit result according to geolocation. > - we will deploy solr anyhow in this project, for a classic > full text search. > > As said above, I'm not really sure if this is a good application > for solr, but the geolocation features are quite handy. And the > query is not really fast in a relational db either. > > Any input is greatly appreciated. > > Regards, > Ewald > > -- Sincerely yours Mikhail Khludnev
