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 itself (easily) to querying exactly how we want.
I implemented the cross-reference caches in Collex knowing it wasn't
very scalable and was implemented very crudely. I think the warming
of these cross-references can be made much smarter (it's braindead
right now, and builds *everything* over again on a single commit of a
single object being tagged) - but I've not yet grasped how to be more
clever with the warming. If I have the full picture of what changed
document-wise between the current searcher and the warming one,
reducing the effort the warmer takes shouldn't be too hard. Can a
warming routine know about what changed precisely?
In short, the JOIN is merely a means to an end. If I can get to that
end with Solr as-is, JOIN? What JOIN?
Erik
On Feb 3, 2007, at 11:40 PM, Ryan McKinley wrote:
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 I'd like solr to handle the JOIN
rather then embed an SQL database and keep two databases synchronized.
If this is at a slight performance hit, thats fine by me!
When speed is the #1 concern, this may not be an option people should
use. Likewise, I don't think the fact this would break federated
searching should deter the ambition to enable a JOIN like support for
solr.
