On Feb 3, 2007, at 4:54 PM, Walter Underwood wrote:
We would never use JOIN. We denormalize for speed. Not a big deal.
So out of curiosity then, what would your design be for indexing
"objects" which have attributes that frequently change and the
quicker you get that reflected to users the better? Consider that
the objects may be large amounts of full-text associated with them as
well.
Erik
wunder
==
Search Guru, Netflix
On 2/3/07 11:16 AM, "Brian Whitman" <[EMAIL PROTECTED]> wrote:
On Feb 2, 2007, at 4:46 PM, Ryan McKinley wrote:
I would LOVE to see a JOIN in SOLR.
I have an index of artists, albums, and songs. The artists have
lots
of metadata and the songs very little. I'd love to be able to
search
for songs using the artist metadata. Right now, I have to add
all the
metadata for each artist and album to each song.
I share my dream with Ryan. My dream API looks like this, sticking
with the artist/track metaphor, in which we have metadata, say the
artist's name, associated to artists that should immediately be
available in track searches:
schema.xml: <aliasField name="artistName" joinOn="artistID">
For track documents, we never <add> with a filled-in artistName. But
whenever we query: type:track artistName:aerosmith bpm:[120 TO 140] ,
the aliasField live searches the solr index for
artistName:aerosmith&fl=artistID, and limits the rest of search space
by those results.
And for each result, if artistName is an aliasField, solr searches on
artistID:X&fl=artistName for each artistID X in the results.
If the field denoted in aliasField is given (as it would be for
artistName in artist-type documents), the aliasField is disabled for
that document.
Possibly insane, possibly breaking the intent of Solr, could get slow
quick, but also very useful.
-Brian
