Welcome, Uwe!
Cheers,
Chris
On 4/1/10 4:05 AM, Grant Ignersoll gsing...@apache.org wrote:
I'm pleased to announce that the Lucene PMC has voted to add Uwe Schindler to
the PMC. Uwe has been doing a lot of work in Lucene and Solr, including
several of the last releases in Lucene.
Please
What are the implications of this this new branding effort with the brands
for the existing Lucene and Solr? Will the names Lucene and Solr cease
in the mainstream in favor of a merged name?
Cheers,
Chris
On 3/22/10 11:02 AM, Steven A Rowe sar...@syr.edu wrote:
Now that Solr and Lucene live
On 3/18/10 11:25 AM, Yonik Seeley ysee...@gmail.com wrote:
On Thu, Mar 18, 2010 at 2:16 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
3.1 may make life easy for us as developers, but is likely to be just as
cofusing to users as if we called the next version Q
We're jumping to version
: We're jumping to version 3.1 because we're releasing at the same time,
: and are based on Lucene 3.1.
You say it like it's a done deal, but I don't get the impression
that i'm the only one who thinks it's unneccessary.
+1, I'm right there with you on this Hoss.
My point is really
: Sorry about the following non serious reply:
:
: It hasn't seemed to hurt the most popular software in the world to be way
: worse than that ;)
:
: 1, 2, 3, NT, 95, 98, 98SE, ME, CE, 2000, XP, 2003, Vista, 2008, 7 (by who's
a) 2000 came out before ME
b) NT, CE, and 2003 (a server
Hi All,
: In the interest of moving forward, perhaps we should just focus on the
: immediate next major release - 3.1. What happens after can wait. We
: never planned for absolutely all the what if's in Solr before the
: merge - I'm not sure why we would need to now.
I suppose, but
Hi Hoss,
: (i suspect a whole lot of people who only care about the core library are
: going to really adamantly not want to have to check out all of Solr just
: to work on the core)
:
: This wouldn't really be merged development now would it?
: When I run 'ant test' I want the Solr
Thanks, Hoss, no problemo, appreciate it!
On 1/26/10 12:22 PM, Chris Hostetter hossman_luc...@fucit.org wrote:
: Not to be a best, but there's no CHANGES.txt updates for SOLR-1516 and
: SOLR-1592. Could someone update them? A trivial patch is attached...
Sorry about that.
Every change (with
Hi Guys,
Not to be a best, but there's no CHANGES.txt updates for SOLR-1516 and
SOLR-1592. Could someone update them? A trivial patch is attached...
Cheers,
Chris
++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet
Dang,
Mailing list stripped the attachment. Here's a link to one:
http://sunset.usc.edu/~mattmann/CHANGES-solr.patch
Cheers,
Chris
On 1/12/10 10:39 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov
wrote:
Hi Guys,
Not to be a best, but there's no CHANGES.txt updates for SOLR-1516
Hi Yonik,
What does this tag mean/do?
Cheers,
Chris
On 12/29/09 12:30 PM, yo...@apache.org yo...@apache.org wrote:
Author: yonik
Date: Tue Dec 29 20:30:53 2009
New Revision: 894477
URL: http://svn.apache.org/viewvc?rev=894477view=rev
Log:
SOLR-1586: add solr-internal tag
Modified:
Hi All,
I've reported SOLR-1602, the jist of which is to move all the response
writers into a new package, o.a.solr.response (and also move
SolrQueryResponse in there).
We know what's required to do this:
SOLR-1602 proposed plan
Thanks, got it!
Cheers,
Chris
On 12/30/09 8:53 AM, Yonik Seeley yo...@lucidimagination.com wrote:
On Wed, Dec 30, 2009 at 11:43 AM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
Hi Yonik,
What does this tag mean/do?
It notifies anyone looking at it that it's subject
Hi Ryan,
Not to throw cold water on the formality... but.. when I suggested we
get broader approval, i was not thinking about jumping into a formal
vote...
Ah, the Apache way :)
Seems odd to put a three day window while many people are on vacation :)
I hear you, but based on mail
Hi Hoss:
On 12/15/09 6:39 PM, Chris Hostetter hossman_luc...@fucit.org wrote:
: a SolrQueryResponse, no one has ever accused any of those response writers
: of not being flexible enough to generate a *different* type of response in
: those formats.
:
: You may be right, but actually
Hey Patrick,
On 12/15/09 9:31 PM, patrick o'leary pj...@pjaol.com wrote:
#1 Change documentation of
http://wiki.apache.org/solr/SolrPlugins#ValueSourceParser to say extends
ValueSourceParser rather than implements.
I updated the Wiki based on your comment.
Cheers,
Chris
Hi Hoss,
On 12/14/09 3:18 PM, Chris Hostetter hossman_luc...@fucit.org wrote:
: Well, I actually would disagree. What's the point of #toInternal and
: #toExternal then, other than to convert from the external representation to
: an internal Lucene index representation, and then to do the
Hi Grant:
By declaring the poly field, you are declaring the dynamic field. I don't see
why this leads to drift. Sure, it is an abstraction and their are Lucene
fields that will be created under the hood, but that is one of the primary
features of Solr, it hides all that mess.
Actually if
Hi Hoss,
: : I think the initial geosearch feature can start off with
: : str10,20/str for a point.
:
: +1.
:
: Fundamentally, how is a string a point?
Fundementally a string is not a point, and a point is not a string -- but
if you want express the concept of a point in a manner
Hi Hoss,
: I think it's rather powerful. You insulate the following variations into 1
: single place to change them (FieldType):
:
: * output representation
: * indexing
: * validation
:
: To remove this from FieldType would be to strew the same functionality
: across multiple classes,
Hi Lance,
On 12/11/09 9:08 PM, Lance Norskog goks...@gmail.com wrote:
There are already components (ExtractingRequestHandler, Deduplication)
that secretly add fields which violate the schema. Personally I would
nuke this ability; I've had major problems with junk in the indexed
data and
Hi Grant,
On 12/10/09 3:16 AM, Grant Ingersoll gsing...@apache.org wrote:
I'm not sure this works, as you need to specify the type of the subfield,
which is what Option B does. I don't think inheritance is the what is going
on here, more like delegation, and that isn't necessarily needed
I¹ll try and hold off, but also work on a patch for option (B+)C :)
On 12/10/09 7:37 AM, Grant Ingersoll gsing...@apache.org wrote:
I have Option B implemented at this point, minus a few tests passing. I'll
put up a patch as soon as I get it working.
Hi All,
While thinking about SOLR-1131, something important just came to mind. If we
allow poly fields to add fields to the schema (be it via dynamic fields, or
explicit field decls, either way), then we introduce a disconnect between
the existing XML schema, and the runtime schema instance. To
Hi Yonik,
While thinking about SOLR-1131, something important just came to mind. If we
allow poly fields to add fields to the schema (be it via dynamic fields, or
explicit field decls, either way), then we introduce a disconnect between
the existing XML schema, and the runtime schema
Hi Grant, and others,
My 2 cents (and of course I'm bias having prepared the patch):
In SOLR-1586, the proposed patch introduces the concept that a Solr response
can declare a namespace for part of the response (in this case, it is using
the tags defined by georss.org to specify a point,
Hi Grant,
My replies inline as well:
Discussion points:
1. If there are standard namespaces, then people can use them to do fun XML
things
+1. This includes things like validation,
Yeah, but the rest of Solr's response doesn't have it, so...
You mean the rest of SOLR's default
.
That alone makes me lean pretty strongly against using a namespace for this.
-Yonik
http://www.lucidimagination.com
On Wed, Dec 9, 2009 at 12:28 PM, Yonik Seeley
yo...@lucidimagination.com wrote:
On Wed, Dec 9, 2009 at 11:44 AM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote
Hi Yonik,
I've run across cases where I added a schema declaration to an XML
file and then things started failing. I think some parsers may
default to validating if it sees that it can?
I've seen this too. But it won't affect the interaction we're talking about
like I said, SOLR-1586
Any parser that does that is so broken that you should stop using it
immediately. --wunder
Walter, totally agree here.
Cheers,
Chris
++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA
Hi All,
: fieldType name=point type=solr.PointType dimension=2
subFieldType=double/
: field name=home type=point indexed=true stored=true/
...
: And a new document of:
: doc
: field name=point39.0 -79.434/field
: /doc
:
: There are three fields created:
: home -- Contains the
Hi Yonik et al.,
I¹d like to add:
Option C: Sub fields are specified as a attribute on the fieldType tag
// needed to essentially define the point type
fieldType name=latlon class=GeoPoint subFieldSuffix=_latlon ../
Hi Yonik,
Using standards enables standard tool development.
We do use standards... lots of them :-) Let's be a bit more specific
though - I was asking about using a namespace for the point type by
*default*, and in isolation (i.e. the rest of solr xml isn't
namespaced), and if/how that
Hi Hoss,
: fieldType name=latlon type=LatLonFieldType pattern=location__* /
: fieldType name=latlon_home type=LatLonFieldType
pattern=location_home_*/
: fieldType name=latlon_work type=LatLonFieldType
pattern=location_home_*/
:
: field name=location type=latlon/
: field
Hey Hoss,
So rather then try to make it entirely magical and behind the scnes, and
still require them to know about it if a collision happens and they get an
error, let's put it right out in front of them so they know about it and
think it through.
+1 to that -- was never trying to make
Hey Hoss,
From: Chris Hostetter [hossman_luc...@fucit.org]
Sent: Monday, November 30, 2009 5:42 PM
To: solr-dev@lucene.apache.org
Subject: Re: SOLR-1131 - Multiple Fields per Field Type
It feels like something we've overlooked in this discussion is whether
Hi Hoss,
On 11/29/09 12:22 PM, Chris Hostetter hossman_luc...@fucit.org wrote:
that would tell them if a field name is currently in use, but not what to
do about it if it is already in use -- FieldType classes shouldn't need
complicated hueristics to figure out somethign the user could
Hey Hoss,
On 11/28/09 4:37 PM, Chris Hostetter hossman_luc...@fucit.org wrote:
One thing that concerns me is potential field name collision -- where one
of these new multifield producing FieldTypes might want to creat a name
that happens to collide with a field the user has already declared.
Hi Guys,
The process should be as formal as the community dictates, but I can't help but
make the observation that increments in version numbers that are strange to
those with some knowledge of artifact versioning will only be stranger to those
without (i.e., adopters/users of SOLR).
To me,
Hi Chris,
Thanks for the inputs: comments inline below:
...i think here may be a disconnect here between some of the goals you are
describing and the purpose of XMLWriter. XMLWriter was originally created
to be a wrapper arround a java.io.Writer that had convinent heper methods
for
Hi Hoss,
Comments inline:
: Potentially -- my problem is, why is XMLWriter a sacred cow? There's not
I'm not trying to suggest that it should be ... my point wasn't to
suggest that we shouldn't modify XMLWriter because it needs to be
preserved as is -- my point was that given
Hey Hoss,
: regular trunk structure at some point down the road. What's the SOLR
: versioning scheme by the way? Is it:
that's part of the problem (and the reason why comments about the back
compat commitments for Solr have come up in this thread) ... Solr is a
young enough project that
Hey Guys,
I'm working on SOLR-1586, and looking at FieldType#toInternal, it just
dawned on me -- how should errors be thrown if a provided value for e.g., a
GeoPointField is not acceptable? As an example, I'm checking lats and lons
for valid ranges (-90 to 90, and -180 to 180, respectively), but
Hey Guys,
I'm trying to report some bugs/improvements, etc., while writing the
GeoField stuff, and there aren't component classifications for JIRA issues
having to do with: schema, and the writer framework. These are major
components that I think warrant a component in JIRA to classify issues
Hey Yonik,
My personal experience with this is if you jump directly to 2.0, you'll have
people wondering where 1.5, 1.6--1.9 is in the CM system, and this would
create some confusion unless it is documented well. This may warrant rethinking
the tag structure a bit in SVN, or perhaps even the
On 11/13/09 11:38 AM, Grant Ingersoll gsing...@apache.org wrote:
If I implement Vincenty's formula for distance between two points on an
ellipsoid that can be accurate down to the 0.5mm. Not doing that yet and not
planning on implementing, so this is not a huge issue right now.
Still, I
Hey Yonik,
Looks great. A couple of comments:
1. How about instead of ... Apache Lucene project. Major features include
powerful full-text search,..., we say ... Apache Lucene project. Its major
features include
powerful full-text search,... [key change: added Its in front of major
features]
47 matches
Mail list logo
