I'm quite open to NOT having a JOIN in Solr if flattening the model
still provides the querying capability desired. I've not fully
followed the specifics that Yonik has mentioned on this thread, but
it certainly is the case that denormalizing/flattening our domain
does not exactly lend its
oops!!! I meant to reply directly to Brian - an old friend of mine
from graduate school...
next time I'll check the reply-to button more closely.
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
...
you share my dream! thats amazing!
I really hope eric persists with the JOIN direction... (its would be
great to get the Lucene in Action guys working on
On 2/3/07, Walter Underwood <[EMAIL PROTECTED]> wrote:
We would never use JOIN. We denormalize for speed. Not a big deal.
I'm looking at an application where speed is not the only concern. If
I can remove the need for a 'normalized' and 'denormalized' form it
would be a HUGE win. Essentially
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
We would never use JOIN. We denormalize for speed. Not a big deal.
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
On Feb 3, 2007, at 11:55 AM, Yonik Seeley wrote:
On 2/3/07, Erik Hatcher <[EMAIL PROTECTED]> wrote:
On Feb 2, 2007, at 4:29 PM, Yonik Seeley wrote:
> One downside of doing joins is that it makes it pretty hard to
> distribute/federate in the future because a document doesn't stand
> alone.
The
On Feb 3, 2007, at 11:18 AM, Yonik Seeley wrote:
Hmmm, classloader hell...
Yeah, I had a bad feeling about that external lib thing. It's a holy
grail to allow dynamic pluggability in Java, but its much more
difficult than it perhaps should be.
I assume you are putting your analyzer in
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
On 2/3/07, Erik Hatcher <[EMAIL PROTECTED]> wrote:
On Feb 2, 2007, at 4:29 PM, Yonik Seeley wrote:
> One downside of doing joins is that it makes it pretty hard to
> distribute/federate in the future because a document doesn't stand
> alone.
The connection between objects is key in our library d
Hmmm, classloader hell...
I assume you are putting your analyzer in solr/lib?
Perhaps try to explode the solr webapp and put your custom analyzer
directly in WEB-INF/lib/
-Yonik
On 2/2/07, Smith,Devon <[EMAIL PROTECTED]> wrote:
Hi,
I'm trying to get a custom tokenizer working, but I'm having
On 2/3/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: print c.search(q='a_dt:["2005-08-01T00:00:00Z" TO "2005-08-01T23:59:59Z"]')
:
: Note that without the quotes around the date in the range query, I get
: an exception because the ':' causes the value to be truncated by the
: queryparser.
uh
Thanks Hoss - I'll give that a try - intuitively that sounds like it'll work
(I'm still new to this - it's not second nature to me just yet!)
On 2/3/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: However, when I run the following search
: foobar date:[2005-08-01T00:00:00Z TO 2005-08-01T23:59
On 2/2/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
LowerCaseAnalyzer does some tokenization (on whitespace i think ... i
cna't remember off hte top of my head) you can also use the
KeywordAnalyzer along with the LowerCaseFilter if you want the entire
string left as a single token (for sorting
14 matches
Mail list logo
