[jira] Assigned: (SOLR-1135) snapshot is created in the directory where solr was lauched
[ https://issues.apache.org/jira/browse/SOLR-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-1135: --- Assignee: Shalin Shekhar Mangar snapshot is created in the directory where solr was lauched --- Key: SOLR-1135 URL: https://issues.apache.org/jira/browse/SOLR-1135 Project: Solr Issue Type: Bug Components: replication (java) Affects Versions: 1.4 Environment: Mac OS 10.5 Reporter: Jianhan Assignee: Shalin Shekhar Mangar Priority: Minor Fix For: 1.4 Attachments: SOLR-1135.patch Original Estimate: 4h Remaining Estimate: 4h when a request http://master_host:port/solr/replication?command=snapshoot is made, a snapshot is created successfully but in a wrong directory. It is not in the data directory (like the script did) but in the directory where solr is launched. This creates complication to backup process because this makes the location of snapshot essential undefined, i.e. depends on how solr is launched. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-629) Fuzzy search with DisMax request handler
[
https://issues.apache.org/jira/browse/SOLR-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12704491#action_12704491
]
Guillaume Smet commented on SOLR-629:
-
bq. FYI: the patch didn't seem to apply cleanly on 1.3, but worked fine on 1.4
The old version of the patch which is still attached should work with 1.3. At
least, I use it on a pre 1.3 version.
The new one is rebased on 1.4 but is the exact same patch.
{quote}
I get this as the parsed query:
parsedquery_toString=+(((title_words:the~0.6)~0.01
(title_words:game~0.6)~0.01)~2) ()
(I don't want it running anything on the word 'the' because its a stop word)
{quote}
AFAIK, it's the standard behaviour for fuzziness (and for wildcard queries).
The stop word isn't removed because the~0.06 != the, it might be another word.
Could any Solr guy confirm?
Note that 0.06 is really too low IMHO. I usually use 0.8 or 0.7 for fuzziness.
--
Guillaume
Fuzzy search with DisMax request handler
Key: SOLR-629
URL: https://issues.apache.org/jira/browse/SOLR-629
Project: Solr
Issue Type: Improvement
Affects Versions: 1.3
Reporter: Guillaume Smet
Priority: Minor
Attachments: dismax_fuzzy_query_field.v0.1.diff,
dismax_fuzzy_query_field.v0.1.diff
The DisMax search handler doesn't support fuzzy queries which would be quite
useful for our usage of Solr and from what I've seen on the list, it's
something several people would like to have.
Following this discussion
http://markmail.org/message/tx6kqr7ga6ponefa#query:solr%20dismax%20fuzzy+page:1+mid:c4pciq6rlr4dwtgm+state:results
, I added the ability to add fuzzy query field in the qf parameter. I kept
the patch as conservative as possible.
The syntax supported is: fieldOne^2.3 fieldTwo~0.3 fieldThree~0.2^-0.4
fieldFour as discussed in the above thread.
The recursive query aliasing should work even with fuzzy query fields using a
very simple rule: the aliased fields inherit the minSimilarity of their
parent, combined with their own one if they have one.
Only the qf parameter support this syntax atm. I suppose we should make it
usable in pf too. Any opinion?
Comments are very welcome, I'll spend the time needed to put this patch in
good shape.
Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1135) snapshot is created in the directory where solr was lauched
[ https://issues.apache.org/jira/browse/SOLR-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-1135. - Resolution: Fixed Committed revision 770082. Thanks Jianhan! snapshot is created in the directory where solr was lauched --- Key: SOLR-1135 URL: https://issues.apache.org/jira/browse/SOLR-1135 Project: Solr Issue Type: Bug Components: replication (java) Affects Versions: 1.4 Environment: Mac OS 10.5 Reporter: Jianhan Assignee: Shalin Shekhar Mangar Priority: Minor Fix For: 1.4 Attachments: SOLR-1135.patch Original Estimate: 4h Remaining Estimate: 4h when a request http://master_host:port/solr/replication?command=snapshoot is made, a snapshot is created successfully but in a wrong directory. It is not in the data directory (like the script did) but in the directory where solr is launched. This creates complication to backup process because this makes the location of snapshot essential undefined, i.e. depends on how solr is launched. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1116) Add a Binary FieldType
[ https://issues.apache.org/jira/browse/SOLR-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12704512#action_12704512 ] Noble Paul commented on SOLR-1116: -- bq.for url-safe base64 (-_ being the extra chars) why do we need it to be url safe?. I guess the binary fields in Lucene is not indexed (Just stored) . If that is the case then we may not need to send it in the 'q' param. Add a Binary FieldType -- Key: SOLR-1116 URL: https://issues.apache.org/jira/browse/SOLR-1116 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.3 Reporter: Noble Paul Fix For: 1.4 Attachments: SOLR-1116.patch, SOLR-1116.patch Lucene supports binary data for field but Solr has no corresponding field type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-629) Fuzzy search with DisMax request handler
[ https://issues.apache.org/jira/browse/SOLR-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12704525#action_12704525 ] Chris Williams commented on SOLR-629: - sorry, it was a typo. I was using 0.6 for the fuzziness, not 0.06. (I have about a week and half experience with solr right now, so bare with me) Assuming you're right about it being the default behavior, is there any alternative way to get it to work? Any fuzzy search with my example above that has a stop word in it doesn't return any results. What kind of field type do you run fuzzy search on? Do you basically just run it on a field that has no filters on it? thanks, Chris Fuzzy search with DisMax request handler Key: SOLR-629 URL: https://issues.apache.org/jira/browse/SOLR-629 Project: Solr Issue Type: Improvement Affects Versions: 1.3 Reporter: Guillaume Smet Priority: Minor Attachments: dismax_fuzzy_query_field.v0.1.diff, dismax_fuzzy_query_field.v0.1.diff The DisMax search handler doesn't support fuzzy queries which would be quite useful for our usage of Solr and from what I've seen on the list, it's something several people would like to have. Following this discussion http://markmail.org/message/tx6kqr7ga6ponefa#query:solr%20dismax%20fuzzy+page:1+mid:c4pciq6rlr4dwtgm+state:results , I added the ability to add fuzzy query field in the qf parameter. I kept the patch as conservative as possible. The syntax supported is: fieldOne^2.3 fieldTwo~0.3 fieldThree~0.2^-0.4 fieldFour as discussed in the above thread. The recursive query aliasing should work even with fuzzy query fields using a very simple rule: the aliased fields inherit the minSimilarity of their parent, combined with their own one if they have one. Only the qf parameter support this syntax atm. I suppose we should make it usable in pf too. Any opinion? Comments are very welcome, I'll spend the time needed to put this patch in good shape. Thanks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Solr Wiki] Update of DataImportHandler by FergusMcMenemie
hi Fergus let us roll this back..
On Thu, Apr 30, 2009 at 10:35 AM, Apache Wiki wikidi...@apache.org wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Solr Wiki for change
notification.
The following page has been changed by FergusMcMenemie:
http://wiki.apache.org/solr/DataImportHandler
The comment on the change is:
typo plus fixing camel case escaping
--
* The datasource configuration can be done in solr config xml
[#solrconfigdatasource also]
* The attribute 'type' specifies the implementation class. It is optional.
The default value is `'JdbcDataSource'`
* The attribute 'name' can be used if there are [#multipleds multiple
datasources] used by multiple entities
- * All other attributes in the dataSource tag are arbitrary. It is
decided by the !DataSource implementation. [#jdbcdatasource See here] for
attributes used by !JdbcDataSource and [#httpds see here] for !URLDataSource
+ * All other attributes in the dataSource tag are arbitrary. It is
decided by the !DataSource implementation. [#jdbcdatasource See here] for
attributes used by !JdbcDataSource and [#httpds see here] for URL!DataSource
* [#datasource See here] for plugging in your own
[[Anchor(multipleds)]]
=== Multiple DataSources ===
@@ -318, +318 @@
DataImportHandler can be used to index data from HTTP based data sources.
This includes using indexing from REST/XML APIs as well as from RSS/ATOM
Feeds.
[[Anchor(httpds)]]
- == Configuration of !URLDataSource ==
+ == Configuration of URLDataSource ==
- A sample configuration in for !URLDataSource in data config xml looks like
this
+ A sample configuration in for URL!DataSource in data config xml looks like
this
{{{
dataSource type=URLDataSource baseUrl=http://host:port/;
encoding=UTF-8 connectionTimeout=5000 readTimeout=1/
}}}
@@ -720, +720 @@
This is the defaut. The !DataSource must be of type
`DataSourceIteratorMapString, Object` . !JdbcDataSource can be used
with this.
=== XPathEntityProcessor ===
- Used when indexing XML type data. The !DataSource must be of type
`DataSourecReader` . !URLDataSource or !FileDataSource is commonly used
with !XPathEntityProcessor.
+ Used when indexing XML type data. The !DataSource must be of type
`DataSourecReader` . URL!DataSource or !FileDataSource is commonly used
with X!PathEntityProcessor.
=== FileListEntityProcessor ===
A simple one which can be used to enumerate the list of files from a File
System based on some criteria. It does not use a !DataSource. The entity
attributes are:
@@ -814, +814 @@
}}}
=== HTTPDataSource ===
- This datasource now deprecated in favor of !URLDataSource. There is no
change in functionality between !URLDataSource and !HTTPDataSource, only a
name change.
+ This datasource is now deprecated in favor of URL!DataSource. There is no
change in functionality between URL!DataSource and !HTTP!DataSource, only a
name change.
=== FileDataSource ===
- This can be used like an !URLDataSource but used to fetch content from
files on disk. The only difference from !URLDataSource, when accessing disk
files, is how a pathname is specified. The signature is as follows
+ This can be used like an URL!DataSource but used to fetch content from
files on disk. The only difference from URL!DataSource, when accessing disk
files, is how a pathname is specified. The signature is as follows
{{{
public class FileDataSource extends DataSourceReader
}}}
@@ -829, +829 @@
=== FieldReaderDataSource ===
! [Solr1.4]
- This can be used like an !URLDataSource . The signature is as follows
+ This can be used like an URL!DataSource . The signature is as follows
{{{
public class FieldReaderDataSource extends DataSourceReader
}}}
@@ -847, +847 @@
=== ContentStreamDataSource ===
! [Solr1.4]
- Use this to use the POST data as the DataSource. This can be used with any
!EntityProcessor that uses a !DataSOurceReader
+ Use this to use the POST data as the DataSource. This can be used with any
!EntityProcessor that uses a !DataSourceReader
== EventListeners ==
!EventListener can be registered for onImportStart and onImportEnd .It
must implement the interface
[http://svn.apache.org/viewvc/lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/EventListener.java?view=markup
EventListener].
@@ -896, +896 @@
There are 3 datasources two RDBMS (jdbc1,jdbc2) and one xml/http (B)
* `jdbc1` and `jdbc2` are instances of type `JdbcDataSource` which are
configured in the solrconfig.xml.
- * `http` is an instance of type `URLDataSource`
+ * `http` is an instance of type `URL!DataSource`
* The root entity starts with a table called 'A' and uses 'jdbc1' as the
datasource . The entity is conveniently named as the table itself
* Entity 'A' has 2
Welcome new Solr committers Mark Miller and Noble Paul
I'm pleased to announce that Mark Miller and Noble Paul have accepted invitations to become Solr committers! Welcome Mark Noble, and thanks for all your great work on Solr! -Yonik ps: following recent custom, why don't you guys tell us a little about yourselves (in addition to adding yourself to http://lucene.apache.org/solr/who.html when you get the karma)
[jira] Created: (SOLR-1136) SQLEntityProcessor- Unnecessary while(true) in nextRow()
SQLEntityProcessor- Unnecessary while(true) in nextRow() Key: SOLR-1136 URL: https://issues.apache.org/jira/browse/SOLR-1136 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Affects Versions: 1.3 Reporter: Amit Nithian Attachments: SOLR-1136.diff Not sure if this is worthy of a JIRA ticket or not but there is an unnecessary while(true) in the nextRow() method in the SQLEntityProcessor. Since there is a return return statement in the loop it doesn't seem to serve a function. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1136) SQLEntityProcessor- Unnecessary while(true) in nextRow()
[ https://issues.apache.org/jira/browse/SOLR-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Nithian updated SOLR-1136: --- Priority: Trivial (was: Major) SQLEntityProcessor- Unnecessary while(true) in nextRow() Key: SOLR-1136 URL: https://issues.apache.org/jira/browse/SOLR-1136 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Affects Versions: 1.3 Reporter: Amit Nithian Priority: Trivial Attachments: SOLR-1136.diff Not sure if this is worthy of a JIRA ticket or not but there is an unnecessary while(true) in the nextRow() method in the SQLEntityProcessor. Since there is a return return statement in the loop it doesn't seem to serve a function. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1137) Improve package naming for DIH
Improve package naming for DIH -- Key: SOLR-1137 URL: https://issues.apache.org/jira/browse/SOLR-1137 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Affects Versions: 1.3 Reporter: Amit Nithian Priority: Minor Currently all classes in the DIH are lumped into one package. I would like to propose a better package naming convention for the DIH: org.apache.solr.handler.dataimport = for those that don't fit into any of the other three but don't warrant their own package yet. org.apache.solr.handler.dataimport.datasource org.apache.solr.handler.dataimport.transformer org.apache.solr.handler.dataimport.processor Create a test folder and mirror the package names for test classes so that test classes are not lumped into src -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
mergeFactor working anymore?
Using a nightly build from 2 nights ago, which has lucene r768336 in it. Since then the number of segments are increasing with every index, and it's looking like mergeFactor is no longer being honored. e.g. have a mergeFactor of 10, but 18 segments in the index. Is there a test case for mergeFactors ? -- Patrick O'Leary AOL Local Search Technologies Phone: + 1 703 265 8763 You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat. - Albert Einstein View Patrick O Leary's profile
Re: mergeFactor working anymore?
On Thu, Apr 30, 2009 at 2:09 PM, patrick o'leary polear...@aol.com wrote: Using a nightly build from 2 nights ago, which has lucene r768336 in it. Since then the number of segments are increasing with every index, and it's looking like mergeFactor is no longer being honored. Is this a testcase (using the solrconfig.xml from the test directory)? If so, I recently changed the settings to create more segments - too many cases were resulting in a single segment, which isn't as good for test coverage. e.g. have a mergeFactor of 10, but 18 segments in the index. mergeFactor 10 means a maximum of 10 segments at each level. if maxBufferedDocs=10 with a log doc merge policy (equivalent to Lucene in the old days), then you could have up to ~ 10*log10(nDocs) segments in the index (i.e. up to 60 segments for a 1M doc index). -Yonik http://www.lucidimagination.com
[jira] Updated: (SOLR-748) FacetComponent helper classes are package restricted
[ https://issues.apache.org/jira/browse/SOLR-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wojtek Piaseczny updated SOLR-748: -- Attachment: SOLR-748.patch Path implements Shalin's suggested changes. FacetComponent helper classes are package restricted Key: SOLR-748 URL: https://issues.apache.org/jira/browse/SOLR-748 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.3 Reporter: Wojtek Piaseczny Assignee: Shalin Shekhar Mangar Fix For: 1.4 Attachments: 748.patch, SOLR-748.patch, SOLR-748.patch, SOLR-748.patch, SOLR-748.patch Original discussion: http://www.nabble.com/Package-Access-Issues---Extending-FacetComponent-to19148122.html The FacetComponent class uses several helper classes that currently have package-restricted access. This makes it impossible to extend the FacetComponent without rewriting most of its functionality. A proposed solution is to make those classes public and make their public member variables accessibly only through get and set functions (i.e. make them private). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-748) FacetComponent helper classes are package restricted
[ https://issues.apache.org/jira/browse/SOLR-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12704748#action_12704748 ] Wojtek Piaseczny edited comment on SOLR-748 at 4/30/09 12:03 PM: - Patch implements Shalin's suggested changes. was (Author: wojtekpia): Path implements Shalin's suggested changes. FacetComponent helper classes are package restricted Key: SOLR-748 URL: https://issues.apache.org/jira/browse/SOLR-748 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.3 Reporter: Wojtek Piaseczny Assignee: Shalin Shekhar Mangar Fix For: 1.4 Attachments: 748.patch, SOLR-748.patch, SOLR-748.patch, SOLR-748.patch, SOLR-748.patch Original discussion: http://www.nabble.com/Package-Access-Issues---Extending-FacetComponent-to19148122.html The FacetComponent class uses several helper classes that currently have package-restricted access. This makes it impossible to extend the FacetComponent without rewriting most of its functionality. A proposed solution is to make those classes public and make their public member variables accessibly only through get and set functions (i.e. make them private). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: mergeFactor working anymore?
On Thu, Apr 30, 2009 at 3:19 PM, Sean Timm tim...@aol.com wrote: Hmmm, the Solr wiki (seems to) states: For example, if you set mergeFactor to 10...there will be no more than 9 segments in each index size. I guess that should say of each segment size or something? It makes a little more sense in the context of that whole paragraph (which is a bit outdated now since flushing and merging is done by the size of the index in bytes). -Yonik http://www.lucidimagination.com
Re: Welcome new Solr committers Mark Miller and Noble Paul
On 30-Apr-09, at 10:41 AM, Yonik Seeley wrote: I'm pleased to announce that Mark Miller and Noble Paul have accepted invitations to become Solr committers! Welcome Mark Noble, and thanks for all your great work on Solr! Congratulations Mark and Noble! Good to have you on board. -Mike
[jira] Resolved: (SOLR-748) FacetComponent helper classes are package restricted
[ https://issues.apache.org/jira/browse/SOLR-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-748. Resolution: Fixed Committed revision 770431. Thanks Wojtek! FacetComponent helper classes are package restricted Key: SOLR-748 URL: https://issues.apache.org/jira/browse/SOLR-748 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.3 Reporter: Wojtek Piaseczny Assignee: Shalin Shekhar Mangar Fix For: 1.4 Attachments: 748.patch, SOLR-748.patch, SOLR-748.patch, SOLR-748.patch, SOLR-748.patch Original discussion: http://www.nabble.com/Package-Access-Issues---Extending-FacetComponent-to19148122.html The FacetComponent class uses several helper classes that currently have package-restricted access. This makes it impossible to extend the FacetComponent without rewriting most of its functionality. A proposed solution is to make those classes public and make their public member variables accessibly only through get and set functions (i.e. make them private). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Best way to gather span/token positions from query?
I've been thinking about how to add spans to Solr, but haven't actually codified it yet. I see no reason why a query parser can't support some syntax and the dump spans method approach can't be co- opted to write out the spans to the response. Seems like it would need to be an additional part of the QueryComponent, plus some addition to the query parsers. We can more easily add it to the Dismax parser, but if we add it to the Lucene one, then we should make that change in Lucene. -Grant On Apr 29, 2009, at 7:06 PM, Sean O'Connor wrote: Hello, I'm trying to find a decent approach for getting token positions out of (or is that into?) solr query results. Is the best approach to extend a QueryComponent and/or HighlightComponent? I'm new to solr, and still on fairly shaky ground soany pointers or suggestions are quite welcome. As a little BACKGROUND: I am trying to migrate a custom lucene-only content anaylsys project to solr. The 'old' system programmatically runs a few thousand predefined queries against a corpus, and then analyzes the results. The lucene score is good, but the actual position of the hits is also quite important. My previous system did a simple query parsing to create SpanQuerys, and then used a modified dumpSpans() to get the token position from the spans. Now I am trying to find how to use solr's goodness (and MemoryIndex approach?) to get the span positions in a more logical manner. I think the answer is in the highlighter, but I'm getting a little twisted around, and could use a pointer. I am using a recent Solr nightly snapshot, grails, Aduna Aperture, and Intellij (if any of that matters) Thanks, Sean -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using Solr/Lucene: http://www.lucidimagination.com/search
Re: Welcome new Solr committers Mark Miller and Noble Paul
On Apr 30, 2009, at 10:41 AM, Yonik Seeley wrote: I'm pleased to announce that Mark Miller and Noble Paul have accepted invitations to become Solr committers! Welcome Mark Noble, and thanks for all your great work on Solr! +1
[jira] Created: (SOLR-1138) Query Elevation Component should gracefully handle empty queries
Query Elevation Component should gracefully handle empty queries
Key: SOLR-1138
URL: https://issues.apache.org/jira/browse/SOLR-1138
Project: Solr
Issue Type: Bug
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
From http://www.lucidimagination.com/search/document/3b50cd3506952f7 :
{quote}
In the QueryElevComponent (QEC) it currently throws an exception if
the input Query is null (line 329).Additionally, I've seen cases
where it's possible that the Query is not null (q is not set, but
q.alt is *:*), but the rb.getQueryString() is null, which causes an
NPE on line 300 or so.
I'd like to suggest that if the Query is empty/null, the QEC should
just go on it's merry way as if there is nothing to do. I don't think
a lack of query means that the QEC is improperly configured, as the
exception message implies:
The QueryElevationComponent needs to be registered 'after' the query
component
We should be making sure the QEC is properly registered during
initialization time.
Thoughts?
-Grant{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Welcome new Solr committers Mark Miller and Noble Paul
hi, I work as a Principal Engineer for AOL in Bangalore . I stumbled upon Solr when my organization asked me to build a search solution for one of AOL's web sites using Solr. I was enamored by the simplicity of the system and Solr has become almost like a hobby for me. Now , I act as a subject matter expert for Solr and various other search solutions implemented in our company. Ever since the start of my career (almost 10 yrs now) I have been breathing java. My work experiences involve building an appserver and a stint at SUN. Building simple , easy to use solutions has been my forte and I hate complexity as I can't handle it myself. My thanks to every one of you for helping me achieve this. cheers, Noble Paul On Thu, Apr 30, 2009 at 11:11 PM, Yonik Seeley yo...@apache.org wrote: I'm pleased to announce that Mark Miller and Noble Paul have accepted invitations to become Solr committers! Welcome Mark Noble, and thanks for all your great work on Solr! -Yonik ps: following recent custom, why don't you guys tell us a little about yourselves (in addition to adding yourself to http://lucene.apache.org/solr/who.html when you get the karma) -- --Noble Paul
