On Feb 13, 2007, at 6:07 PM, Yonik Seeley wrote:
On 2/12/07, Erik Hatcher <[EMAIL PROTECTED]> wrote:
And just for the record, Solr drives Collex @ NINES: which implements tagging along with faceted and
full-text search. I've recently hacked our system such that the bulk
of our custom caches
On 2/12/07, Erik Hatcher <[EMAIL PROTECTED]> wrote:
On Feb 12, 2007, at 9:10 PM, Gmail Account wrote:
> This would be great! I can't help with the solution but I am very
> interested in using it if one of you guys can figure it out.
>
> I can't wait to see if this works out.
And just for the re
On Feb 12, 2007, at 9:10 PM, Gmail Account wrote:
This would be great! I can't help with the solution but I am very
interested in using it if one of you guys can figure it out.
I can't wait to see if this works out.
And just for the record, Solr drives Collex @ NINES: www.nines.org/collex>
February 06, 2007 4:51 AM
Subject: Re: convert custom facets to Solr facets...
Yonik - this is great! Thanks for codifying the use cases and providing
a possible implementation. I'll tinker with this more when I can.
Erik
On Feb 4, 2007, at 2:13 PM, Yonik Seeley wrote:
I was co
Yonik - this is great! Thanks for codifying the use cases and
providing a possible implementation. I'll tinker with this more when
I can.
Erik
On Feb 4, 2007, at 2:13 PM, Yonik Seeley wrote:
I was confusing myself too much without nailing down more concrete
examples,
so I too
I was confusing myself too much without nailing down more concrete examples,
so I took a shot at coming up with user tagging usecases and
a way to implement them with a flat schema.
The usecases may be biased toward a flat schema since that's what I
had in mind... so feel free to add more, or cha
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 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
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 domain though.
A flat structure for tagging could be t
The index has a "type" field: "A" for archived objects and "C" for
collectibles. All the original objects are indexed in batch fashion
as type "A". Users collect objects and tags/annotates them. When a
user collects an object, a document of type "C" is indexed with the
original objects unique
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.
A flat structure for tagging could be to add a
taguser and tag field to the actual document each time a user tagged a document.
- all collected objects
fa
Before Solr had facets, I built my own implementation in a much
cruder and less performant way into Collex as custom request handlers.
Now the performance issue of warming up the cache needs to be
addressed. I'm going to upgrade Solr and adjust the application to
work with the built-in fac
19 matches
Mail list logo
