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
feat
Hi Folks,
My +1 for the release.
1. MD5 sums verify:
[chipotle:~] mattmann% cat apache-solr-1.4.0.tgz.md5
03729c1d9e5bc334605bf6f41a17ed51 apache-solr-1.4.0.tgz
[chipotle:~] mattmann%
[chipotle:~] mattmann% md5 apache-solr-1.4.0.tgz
MD5 (apache-solr-1.4.0.tgz) = 03729c1d9e5bc334605bf6f41a17ed5
On 11/13/09 11:38 AM, "Grant Ingersoll" 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 think we should
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 r
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 I
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 with
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 ge
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 XMLWr
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 proje
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, to
Hey Hoss,
On 11/28/09 4:37 PM, "Chris Hostetter" 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.
Since FieldTypes a
Hi Hoss,
On 11/29/09 12:22 PM, "Chris Hostetter" 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 configure.
>
Maybe, but
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 a
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,
>
> :
> : pattern="location_home_*"/>
> : pattern="location_home_*"/>
> :
> :
> :
> :
>
> I'm not really understanding the value of an approach like that. for
> starters, what Lucene field names would ultimately be created in those
> examples?
The first field would be named lo
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, et
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 S
Hi Yonik,
Thanks. Replies below:
> My gut feeling is that we should not be introducing namespaces by default.
> It introduces a new requirement of XML parsers in clients, and some
> parsers would start validating by default, and going out to the web to
> retrieve the referenced namespace/schema,
em barf.
> 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
> wrote:
>> On Wed, Dec 9, 2009 at 11:44 AM, Mattmann, Chris A (388J)
>&
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 ou
Hi Yonik:
>
> If you're forced to declare the namespace / put the URI, I'm just
> afraid of what clients / XML parsers out there may start trying to
> validate by default.
And even if they did, it's valid XML so what's the problem?
> And I'm still trying to figure out what we gain.
* plugging
> 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, C
Hi Hoss,
> : I think the initial geosearch feature can start off with
> : 10,20 for a point.
>
> +1.
Fundamentally, how is a string a point?
>
> The current XML format SOlr uses was designed to be extremely simple, very
> JSON-esque, and easily parsable by *anyone* in any langauge, without
> n
Hi Hoss,
> : ...unless things have changed since hte last time i looked, all of the
> : "out of the box" response writers call "toString()" on any object they
> : don't understand. So the best way to move forward in a flexible manner
> : seems like it would be to add a new "GeoPoint" object to So
Hi All,
>>
>> : > subFieldType="double"/>
>> :
>> ...
>> : And a new document of:
>> :
>> : 39.0 -79.434
>> :
>> :
>> : There are three fields created:
>> : home -- Contains the stored value
>> : home___0 - Contains 39.0 indexed as a double (as in the "double" FieldType,
>> not just a d
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
// uses of the latlon type
// subFieldSuffix is appended to th
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
Hi Grant,
On 12/10/09 3:16 AM, "Grant Ingersoll" 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 for all
> impl
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" 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 my
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 i
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
Hi Hoss,
> : > : I think the initial geosearch feature can start off with
> : > : 10,20 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 mann
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 cl
Hi Lance,
On 12/11/09 9:08 PM, "Lance Norskog" 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 discovering secr
Hi Hoss,
On 12/14/09 3:18 PM, "Chris Hostetter" 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 opposite coming
> : o
Hi Hoss:
On 12/15/09 6:39 PM, "Chris Hostetter" 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 quite a few i
Hey Patrick,
On 12/15/09 9:31 PM, "patrick o'leary" 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 Yonik,
What does this tag mean/do?
Cheers,
Chris
On 12/29/09 12:30 PM, "yo...@apache.org" wrote:
> Author: yonik
> Date: Tue Dec 29 20:30:53 2009
> New Revision: 894477
>
> URL: http://svn.apache.org/viewvc?rev=894477&view=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" wrote:
> On Wed, Dec 30, 2009 at 11:43 AM, Mattmann, Chris A (388J)
> wrote:
>> Hi Yonik,
>>
>> What does this tag mean/do?
>
> It notifies anyone looking at it that it's &q
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 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 Propulsi
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)"
wrote:
Hi Guys,
Not to be a best, but there's no CHANGES.txt updates for SOLR-1516 and
SOLR
Thanks, Hoss, no problemo, appreciate it!
On 1/26/10 12:22 PM, "Chris Hostetter" 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 the possible exception
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 S
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 suppo
On 3/18/10 11:25 AM, "Yonik Seeley" wrote:
> On Thu, Mar 18, 2010 at 2:16 PM, Chris Hostetter
> 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 3.1 because we're releasing a
>
> : 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 re
>
>
> : 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 200
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" wrote:
> Now that Solr and Lucene live in the sa
Welcome, Uwe!
Cheers,
Chris
On 4/1/10 4:05 AM, "Grant Ignersoll" 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 join me in extending
52 matches
Mail list logo
