Thanks for the history and the current state of trunk, guys. It sounds like
it's rather stable for serious use... in which case it's probably ready for
a release, but let's not go back in circles. :) I'll give it a shot
sometime.
Thanks, again!
--
View this message in context:
http://lucene.4720
On Aug 2, 2011, at 5:47 PM, eks dev wrote:
> Sure, I know...,
> the point I was trying to make, "if someone serious like Lucid is
> using solr 4.x as a core technology for own customers, the trunk could
> not be all that bad" => release date not as far as 2012 :)
Oh the current trunk is most def
Sure, I know...,
the point I was trying to make, "if someone serious like Lucid is
using solr 4.x as a core technology for own customers, the trunk could
not be all that bad" => release date not as far as 2012 :)
On Tue, Aug 2, 2011 at 11:33 PM, Smiley, David W. wrote:
> "LucidWorks Enterprise"
"LucidWorks Enterprise" (which is more than Solr, and a modified Solr at that)
isn't free; so you can't extract the Solr part of that package and use it
unless you are willing to pay them.
Lucid's "Certified Solr", on the other hand, is free. But they have yet to
bump that to trunk/4.x; it was
Well, Lucid released "LucidWorks Enterprise"
with " Complete Apache Solr 4.x Release Integrated and tested with
powerful enhancements"
Whatever it means for solr 4.0
On Tue, Aug 2, 2011 at 11:10 PM, David Smiley (@MITRE.org)
wrote:
> My best guess (and it is just a guess) is between December
My best guess (and it is just a guess) is between December and March.
The roots of Solr 4 which triggered the major version change is known as
"flexible indexing" (or just "flex" for short amongst developers). The
genesis of it was posted to JIRA as a patch on 18 November 2008 --
LUCENE-1458 (a
Thanks. I saw the related jira issue but didn't follow closely enough to see
the cross-core join being added later. Any idea/hint on when I can expect
Solr 4 to be released?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Matching-queries-on-a-per-element-basis-against-a-multi
On Aug 2, 2011, at 1:09 PM, Suk-Hyun Cho [via Lucene] wrote:
> I appreciate your replies and ideas.
>
> SpanQuery would work, and I'll look into this further. However, what about
> the original question? Is there no way to match documents on a per-element
> basis against a multivalued field?
I appreciate your replies and ideas.
SpanQuery would work, and I'll look into this further. However, what about
the original question? Is there no way to match documents on a per-element
basis against a multivalued field? If not, would it perhaps make sense to
create a feature request?
Also, rega
Suk,
You're hitting on a well known limitation with Lucene, and the "solutions"
are work-arounds that may be unacceptable depending on the specifics of your
case.
Solr 4.0 (trunk)'s support for Joins is definitely an up and coming option,
as Mike pointed out.
Kersen's suggestion of using an ind
Hi Suk-Hyun Cho,
if "myFriend" is the unit of retrieval you should use this as lucene document
with the fields "isCool" "gender" "bloodType" ...
if you realy want to insert all "myFriends" in one field like your
myFriends = [
"isCool=true SOME_JUNK_HERE gender=female bloodType=O",
"isCoo
You have a few choices:
1) flatten your field structure - like your "undesirable" example, but
wouldn't you want to have the document identifier as a field value also?
2) use phrase queries to make sure the key/value pairs are adjacent
3) use a join query
That's all I can think of
-Mike
On
12 matches
Mail list logo
