Ooops. On Aug 14, 2013, at 4:12 PM, Ted Yu <[email protected]> wrote:
> bq. JOIN is not supported in Phoenix > > That is correct. > > See https://github.com/forcedotcom/Phoenix/wiki > > On Wed, Aug 14, 2013 at 2:04 PM, Vladimir Rodionov > <[email protected]>wrote: > >> Michael, JOIN is not supported in Phoenix for very obvious reasons and will >> probably never be (may be except of JOIN against replicated tables) . >> >> >> On Wed, Aug 14, 2013 at 1:52 PM, Andrew Purtell <[email protected]> >> wrote: >> >>> On Wed, Aug 14, 2013 at 8:45 AM, Michael Segel < >> [email protected] >>>> wrote: >>> >>>> This isn't too bad if you're doing a simple query against one index. >> You >>>> can do the work by RS and then join the results from all RS. >>>> >>>> However… what happens if you have two indexes and your result set is >>> going >>>> to be the intersection of the indexes? >>>> >>>> Or you're going to do a join between two tables using the indexes to >>> limit >>>> the result set? >>>> >>>> Now your design breaks down quickly. >>>> >>> >>> You may have just described their design assumptions. >>> >>> I'm not endorsing this per se, but suggesting it is not a good idea on >>> account it can't live up to the requirements of a pretty particular >>> strawman seems a step too far. >>> >>> Maybe someone from Huawei can talk a bit here about successful use cases? >>> >>>> You could also look at Lucene which we did a PoC a few years back. >>> >>> A certain large technology company has an HBase full text index built on >>> Lucene that might be offered as a contribution at some point. From what I >>> know of it, there are a different set of tradeoffs and it certainly won't >>> work for everyone, and not because the people working on it were not >> smart >>> enough to find a silver bullet. >>> >>> -- >>> Best regards, >>> >>> - Andy >>> >>> Problems worthy of attack prove their worth by hitting back. - Piet Hein >>> (via Tom White) >>> >> The opinions expressed here are mine, while they may reflect a cognitive thought, that is purely accidental. Use at your own risk. Michael Segel michael_segel (AT) hotmail.com
