[jira] Commented: (SOLR-1653) add PatternReplaceCharFilter

[Shalin Shekhar Mangar (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790026#action_12790026
 ] 

Shalin Shekhar Mangar commented on SOLR-1653:
-

Koji, even after reading through the test, I do not understand how to use it. 
Are the characters in curly braces, written down for non-groups only? What if I 
want to remove one particular group?

It is always good to write a use-case and an example in the issue description 
itself.

> add PatternReplaceCharFilter
> 
>
> Key: SOLR-1653
> URL: https://issues.apache.org/jira/browse/SOLR-1653
> Project: Solr
>  Issue Type: New Feature
>  Components: Schema and Analysis
>Affects Versions: 1.4
>Reporter: Koji Sekiguchi
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1653.patch
>
>
> Add a new CharFilter that uses a regular expression for the target of replace 
> string in char stream.
> Usage:
> {code:title=schema.xml}
>  positionIncrementGap="100" >
>   
>  groupedPattern="([nN][oO]\.)\s*(\d+)"
> replaceGroups="1,2" blockDelimiters=":;"/>
>  mapping="mapping-ISOLatin1Accent.txt"/>
> 
>   
> 
> {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1654) Add TikaEntityProcessor example to the DIHExample

[Noble Paul (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Noble Paul updated SOLR-1654:
-

Summary: Add TikaEntityProcessor example to the DIHExample  (was: Add 
TikaEntityProcessor example as part of "ant example")

> Add TikaEntityProcessor example to the DIHExample
> -
>
> Key: SOLR-1654
> URL: https://issues.apache.org/jira/browse/SOLR-1654
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Affects Versions: 1.4
>Reporter: Akshay K. Ukey
>Priority: Minor
> Fix For: 1.5
>
>
> As part of "ant example" a sample tika setup should be generated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SOLR-1654) Add TikaEntityProcessor example as part of "ant example"

[Akshay K. Ukey (JIRA)]

Add TikaEntityProcessor example as part of "ant example"


 Key: SOLR-1654
 URL: https://issues.apache.org/jira/browse/SOLR-1654
 Project: Solr
  Issue Type: Improvement
  Components: contrib - DataImportHandler
Affects Versions: 1.4
Reporter: Akshay K. Ukey
Priority: Minor
 Fix For: 1.5


As part of "ant example" a sample tika setup should be generated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (SOLR-1177) Distributed TermsComponent

[Shalin Shekhar Mangar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shalin Shekhar Mangar resolved SOLR-1177.
-

Resolution: Fixed

Committed revision 890199.

Thanks Matt!

> Distributed TermsComponent
> --
>
> Key: SOLR-1177
> URL: https://issues.apache.org/jira/browse/SOLR-1177
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Matt Weber
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1177.patch, SOLR-1177.patch, SOLR-1177.patch, 
> SOLR-1177.patch, SOLR-1177.patch, SOLR-1177.patch, TermsComponent.java, 
> TermsComponent.patch
>
>
> TermsComponent should be distributed

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1177) Distributed TermsComponent

[Shalin Shekhar Mangar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shalin Shekhar Mangar updated SOLR-1177:


Attachment: SOLR-1177.patch

{code}
if (tc.getFrequency() >= freqmin && tc.getFrequency() <= freqmax) {
  fieldterms.add(tc.getTerm(), ((Number)tc.getFrequency()).intValue()); cnt++; 
}
{code}

I changed freqmin and freqmax to long and used Yonik's method to write int if 
possible or else switch to longs in the response.

I'll commit this shortly.

> Distributed TermsComponent
> --
>
> Key: SOLR-1177
> URL: https://issues.apache.org/jira/browse/SOLR-1177
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Matt Weber
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1177.patch, SOLR-1177.patch, SOLR-1177.patch, 
> SOLR-1177.patch, SOLR-1177.patch, SOLR-1177.patch, TermsComponent.java, 
> TermsComponent.patch
>
>
> TermsComponent should be distributed

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1277) Implement a Solr specific naming service (using Zookeeper)

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790008#action_12790008
 ] 

Noble Paul commented on SOLR-1277:
--

why should the ZookeeperController reference be kept in SolrCore also? Can it 
not be fetched just in time from CoreContainer?

> Implement a Solr specific naming service (using Zookeeper)
> --
>
> Key: SOLR-1277
> URL: https://issues.apache.org/jira/browse/SOLR-1277
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
> Attachments: log4j-1.2.15.jar, SOLR-1277.patch, SOLR-1277.patch, 
> SOLR-1277.patch, SOLR-1277.patch, zookeeper-3.2.1.jar
>
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> The goal is to give Solr server clusters self-healing attributes
> where if a server fails, indexing and searching don't stop and
> all of the partitions remain searchable. For configuration, the
> ability to centrally deploy a new configuration without servers
> going offline.
> We can start with basic failover and start from there?
> Features:
> * Automatic failover (i.e. when a server fails, clients stop
> trying to index to or search it)
> * Centralized configuration management (i.e. new solrconfig.xml
> or schema.xml propagates to a live Solr cluster)
> * Optionally allow shards of a partition to be moved to another
> server (i.e. if a server gets hot, move the hot segments out to
> cooler servers). Ideally we'd have a way to detect hot segments
> and move them seamlessly. With NRT this becomes somewhat more
> difficult but not impossible?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1123) Change the JSONResponseWriter content type

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789998#action_12789998
 ] 

Noble Paul commented on SOLR-1123:
--

bq. I always had the impression that the main idea behind the response writers 
is that all they need to know is how to marshal a NamedList ...

That is the problem. the NamedList is a weird datastructure for those who are 
not so used to Solr. You don't know what is included in that unless you do an 
instanceof. Most of the users are happy to write out the documents . 
understanding a SolrDocument is far easier than figuring outhow to handle a 
DocList .So it is an attempt to cater to those needs .  

If you know how to handle the NamedList beast then you can do that also ( but 
only if you wish to). 

> Change the JSONResponseWriter content type
> --
>
> Key: SOLR-1123
> URL: https://issues.apache.org/jira/browse/SOLR-1123
> Project: Solr
>  Issue Type: Improvement
>Reporter: Uri Boness
> Fix For: 1.5
>
> Attachments: JSON_contentType_incl_tests.patch
>
>
> Currently the jSON content type is not used. Instead the palin/text content 
> type is used. The reason for this as I understand is to enable viewing the 
> json response as as text in the browser. While this is valid argument, I do 
> believe that there should at least be an option to configure this writer to 
> use the JSON content type. According to 
> [RFC4627|http://www.ietf.org/rfc/rfc4627.txt] the json content type needs to 
> be application/json (and not text/x-json). The reason this can be very 
> helpful is that today you have plugins for browsers (e.g. 
> [JSONView|http://brh.numbera.com/software/jsonview]) that can render any page 
> with application/json content type in a user friendly manner (just like xml 
> is supported).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1621) Allow current single core deployments to be specified by solr.xml

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789988#action_12789988
 ] 

Noble Paul commented on SOLR-1621:
--

bq.Personally, I'd prefer a form of deprecation first.

me too.  But this looked like an exception. This is rarely used (if at all) and 
according to me is a bad feature because it needs editing web.xml . 

bq.At a minimum, it needs to be its own issue so that the warning to users that 
they need to change what they are doing is very clear.

There is another issue now SOLR-1647 .I should change the language. they are 
really not deprecations. 

Ok . I can go both ways on this. we can keep the feature deprecated and remove 
it later or remove it right away. My preference would be to remove it.



> Allow current single core deployments to be specified by solr.xml
> -
>
> Key: SOLR-1621
> URL: https://issues.apache.org/jira/browse/SOLR-1621
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: 1.5
>Reporter: Noble Paul
> Fix For: 1.5
>
> Attachments: SOLR-1621.patch, SOLR-1621.patch, SOLR-1621.patch, 
> SOLR-1621.patch, SOLR-1621.patch, SOLR-1621.patch, SOLR-1621.patch, 
> SOLR-1621.patch, SOLR-1621.patch
>
>
> supporting two different modes of deployments is turning out to be hard. This 
> leads to duplication of code. Moreover there is a lot of confusion on where 
> do we put common configuration. See the mail thread 
> http://markmail.org/message/3m3rqvp2ckausjnf

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1644) Provide a clean way to keep flags and helper objects in ResponseBuilder

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789986#action_12789986
 ] 

Noble Paul commented on SOLR-1644:
--

bq.But perhaps we should have gone with the same strategy as the 
UpdateProcessorChain

yes, it is. because there are more than one method call per component per 
request. Should we still try to do it?

bq.Changing from a method or member to a hash lookup doesn't reduce a 
dependency when it's needed.

not true. The fact is that ResponseBuilder stops depending on other components 
. It is ok for components to depend on  ResponseBuilder.

bq. I believe a Store interface can help here which provide access to data by a 
key 

Looks better. 

> Provide a clean way to keep flags and helper objects in ResponseBuilder
> ---
>
> Key: SOLR-1644
> URL: https://issues.apache.org/jira/browse/SOLR-1644
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.5
>
> Attachments: SOLR-1644.patch
>
>
> Many components such as StatsComponent, FacetComponent etc keep flags and 
> helper objects in ResponseBuilder. Having to modify the ResponseBuilder for 
> such things is a very kludgy solution.
> Let us provide a clean way for components to keep arbitrary objects for the 
> duration of a (distributed) search request.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1653) add PatternReplaceCharFilter

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789957#action_12789957
 ] 

Koji Sekiguchi commented on SOLR-1653:
--

I'll commit in a few days.

> add PatternReplaceCharFilter
> 
>
> Key: SOLR-1653
> URL: https://issues.apache.org/jira/browse/SOLR-1653
> Project: Solr
>  Issue Type: New Feature
>  Components: Schema and Analysis
>Affects Versions: 1.4
>Reporter: Koji Sekiguchi
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1653.patch
>
>
> Add a new CharFilter that uses a regular expression for the target of replace 
> string in char stream.
> Usage:
> {code:title=schema.xml}
>  positionIncrementGap="100" >
>   
>  groupedPattern="([nN][oO]\.)\s*(\d+)"
> replaceGroups="1,2" blockDelimiters=":;"/>
>  mapping="mapping-ISOLatin1Accent.txt"/>
> 
>   
> 
> {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1621) Allow current single core deployments to be specified by solr.xml

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789926#action_12789926
 ] 

Mark Miller commented on SOLR-1621:
---

bq. The setSolrConfigFilename() did not work for multicore . 

But it did work for single core, and we are emulating that. I agree that it 
should be removed, but perhaps not in how. I think it should go away with 
warning - and I don't think we should mark something as deprecated when it just 
no longer works - deprecation means the method should still work. Also, I'm not 
sure if you have realized it yet, but tests currently rely on this 
functionality - it cannot be pulled without replacing the functionality for 
tests in some manner.

bq. So it does not make sense for us to bend over backwards to make it work in 
this and add too many overloaded methods. 

It doesn't require bending over backwards. It doesn't even require overloaded 
methods (see my latest patch) - that was just one method.


bq. Anyway, users won't need

Its not about users needing this - they won't need it because they can now use 
solr.xml - its about functionality that someone is currently counting on simply 
disappearing. Personally, I'd prefer a form of deprecation first. At a minimum, 
it needs to be its own issue so that the warning to users that they need to 
change what they are doing is *very* clear.

> Allow current single core deployments to be specified by solr.xml
> -
>
> Key: SOLR-1621
> URL: https://issues.apache.org/jira/browse/SOLR-1621
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: 1.5
>Reporter: Noble Paul
> Fix For: 1.5
>
> Attachments: SOLR-1621.patch, SOLR-1621.patch, SOLR-1621.patch, 
> SOLR-1621.patch, SOLR-1621.patch, SOLR-1621.patch, SOLR-1621.patch, 
> SOLR-1621.patch, SOLR-1621.patch
>
>
> supporting two different modes of deployments is turning out to be hard. This 
> leads to duplication of code. Moreover there is a lot of confusion on where 
> do we put common configuration. See the mail thread 
> http://markmail.org/message/3m3rqvp2ckausjnf

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1277) Implement a Solr specific naming service (using Zookeeper)

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789927#action_12789927
 ] 

Mark Miller commented on SOLR-1277:
---

I started hacking in a wait rather than a pause on client connections. Its not 
a complete and thorough solution, but it starts us down that path.

Interesting that both of us only see the issue on windows and not linux - your 
linux box must be really fast too :)

> Implement a Solr specific naming service (using Zookeeper)
> --
>
> Key: SOLR-1277
> URL: https://issues.apache.org/jira/browse/SOLR-1277
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
> Attachments: log4j-1.2.15.jar, SOLR-1277.patch, SOLR-1277.patch, 
> SOLR-1277.patch, SOLR-1277.patch, zookeeper-3.2.1.jar
>
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> The goal is to give Solr server clusters self-healing attributes
> where if a server fails, indexing and searching don't stop and
> all of the partitions remain searchable. For configuration, the
> ability to centrally deploy a new configuration without servers
> going offline.
> We can start with basic failover and start from there?
> Features:
> * Automatic failover (i.e. when a server fails, clients stop
> trying to index to or search it)
> * Centralized configuration management (i.e. new solrconfig.xml
> or schema.xml propagates to a live Solr cluster)
> * Optionally allow shards of a partition to be moved to another
> server (i.e. if a server gets hot, move the hot segments out to
> cooler servers). Ideally we'd have a way to detect hot segments
> and move them seamlessly. With NRT this becomes somewhat more
> difficult but not impossible?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1644) Provide a clean way to keep flags and helper objects in ResponseBuilder

[Yonik Seeley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789925#action_12789925
 ] 

Yonik Seeley commented on SOLR-1644:


bq. definitely it looks verbose (ugly) . But the point is where do we stop?

Where it makes sense.  There's no reason for an all or nothing approach.  
There's no reason not to give some special treatment to some main components.

If one want's to better decompose some of the state for each handler, I guess 
there could be objects that represented that too?
class ResponseBuilder {
  QueryInfo queryInfo;
  FacetInfo facetInfo;
}

But perhaps we should have gone with the same strategy as the 
UpdateProcessorChain... an actual object is created for each component to keep 
the state for the request.

bq. I believe the public API's should have no dependency on components .

Changing from a method or member to a hash lookup doesn't reduce a dependency 
when it's needed.



> Provide a clean way to keep flags and helper objects in ResponseBuilder
> ---
>
> Key: SOLR-1644
> URL: https://issues.apache.org/jira/browse/SOLR-1644
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.5
>
> Attachments: SOLR-1644.patch
>
>
> Many components such as StatsComponent, FacetComponent etc keep flags and 
> helper objects in ResponseBuilder. Having to modify the ResponseBuilder for 
> such things is a very kludgy solution.
> Let us provide a clean way for components to keep arbitrary objects for the 
> duration of a (distributed) search request.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1123) Change the JSONResponseWriter content type

[Chris A. Mattmann (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789923#action_12789923
 ] 

Chris A. Mattmann commented on SOLR-1123:
-

{quote}
I think the main issue with the inheritance right now is that the 
QueryResponseWriter interface is dealing with a Writer rather than with an 
OutputStream. This accounts for the hacky GenericBinaryResponseWriter. 
{quote}

I'm taking a look at this.

{quote}
Looking at SOLR-1516 I'm a bit confused. I always had the impression that the 
main idea behind the response writers is that all they need to know is how to 
marshal a NamedList (so they don't need explicit knowledge of documents, 
highlighting, etc...). But now the GenericTextResponseWriter knows about 
documents (via the SingleResponseWriter). But perhaps I just go it wrong.
{quote}

Well if that's the main idea behind ResponseWriters as you put it, then as I 
put it in SOLR-1516, it's pretty confusing. Users (who understand Lucene and 
SOLR) know that if they query they get back o.a.lucene.Documents or 
o.a.solr.SolrDocumentList, etc. The whole NamedList structure is pretty 
confusing to me (and to others as I've noted on other issues and on the mailing 
list). SOLR-1516 was an attempt to give those people writing ResponseWriters 
(now) the ability to deal with results of queries, aka Documents (and not all 
the other NamedList typeless bag of objects where you have to do instanceof 
everwhere to unmarshall it). Clearly not all ResponseWriters will be able to 
take advantage of this (e.g., those that need the specified output structures 
provided by other components, e.g., Facets, etc.), which is why my original 
patch called the two response writers I added Document*ResponseWriter b/c 
that's what they dealt with.

Cheers,
Chris


> Change the JSONResponseWriter content type
> --
>
> Key: SOLR-1123
> URL: https://issues.apache.org/jira/browse/SOLR-1123
> Project: Solr
>  Issue Type: Improvement
>Reporter: Uri Boness
> Fix For: 1.5
>
> Attachments: JSON_contentType_incl_tests.patch
>
>
> Currently the jSON content type is not used. Instead the palin/text content 
> type is used. The reason for this as I understand is to enable viewing the 
> json response as as text in the browser. While this is valid argument, I do 
> believe that there should at least be an option to configure this writer to 
> use the JSON content type. According to 
> [RFC4627|http://www.ietf.org/rfc/rfc4627.txt] the json content type needs to 
> be application/json (and not text/x-json). The reason this can be very 
> helpful is that today you have plugins for browsers (e.g. 
> [JSONView|http://brh.numbera.com/software/jsonview]) that can render any page 
> with application/json content type in a user friendly manner (just like xml 
> is supported).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1123) Change the JSONResponseWriter content type

[Uri Boness (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789922#action_12789922
 ] 

Uri Boness commented on SOLR-1123:
--

I think the main issue with the inheritance right now is that the 
QueryResponseWriter interface is dealing with a Writer rather than with an 
OutputStream. This accounts for the hacky GenericBinaryResponseWriter. 

Looking at SOLR-1516 I'm a bit confused. I always had the impression that the 
main idea behind the response writers is that all they need to know is how to 
marshal a NamedList (so they don't need explicit knowledge of documents, 
highlighting, etc...). But now the GenericTextResponseWriter knows about 
documents (via the SingleResponseWriter). But perhaps I just go it wrong.

> Change the JSONResponseWriter content type
> --
>
> Key: SOLR-1123
> URL: https://issues.apache.org/jira/browse/SOLR-1123
> Project: Solr
>  Issue Type: Improvement
>Reporter: Uri Boness
> Fix For: 1.5
>
> Attachments: JSON_contentType_incl_tests.patch
>
>
> Currently the jSON content type is not used. Instead the palin/text content 
> type is used. The reason for this as I understand is to enable viewing the 
> json response as as text in the browser. While this is valid argument, I do 
> believe that there should at least be an option to configure this writer to 
> use the JSON content type. According to 
> [RFC4627|http://www.ietf.org/rfc/rfc4627.txt] the json content type needs to 
> be application/json (and not text/x-json). The reason this can be very 
> helpful is that today you have plugins for browsers (e.g. 
> [JSONView|http://brh.numbera.com/software/jsonview]) that can render any page 
> with application/json content type in a user friendly manner (just like xml 
> is supported).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1644) Provide a clean way to keep flags and helper objects in ResponseBuilder

[Uri Boness (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789920#action_12789920
 ] 

Uri Boness commented on SOLR-1644:
--

bq. if (rb.store.get(HighlightingComponent.DO_HIGHLIGHTING) == Boolean.TRUE)

This is verbose... too verbose to my taste. I believe a Store interface can 
help here which provide access to data by a key and will also provide helper 
methods to keep the code clean. (a MapStore can be a simple implementation 
which wraps a Map instance):

{code}
public interface Context {

Boolean getBoolean(String key);
boolean getBoolean(String key, boolean defaultValue);

Integer getInt(String key);
int getInt(String key, int defaultValue);

//other methods for all primitive types and dates.
}
{code}

so now you have:

{code}
if (rb.store.getBoolean(HighlightingComponent.DO_HIGHLIGHTING, false))
{code}

which is cleaner and is NPE-safe.

bq. I believe the public API's should have no dependency on components .
I agree. Basically avoid having circular dependencies. You don't want to change 
the platform API every time you introduce a new component.

> Provide a clean way to keep flags and helper objects in ResponseBuilder
> ---
>
> Key: SOLR-1644
> URL: https://issues.apache.org/jira/browse/SOLR-1644
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.5
>
> Attachments: SOLR-1644.patch
>
>
> Many components such as StatsComponent, FacetComponent etc keep flags and 
> helper objects in ResponseBuilder. Having to modify the ResponseBuilder for 
> such things is a very kludgy solution.
> Let us provide a clean way for components to keep arbitrary objects for the 
> duration of a (distributed) search request.

-- 
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-1644) Provide a clean way to keep flags and helper objects in ResponseBuilder

[Uri Boness (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789920#action_12789920
 ] 

Uri Boness edited comment on SOLR-1644 at 12/13/09 6:13 PM:


bq. if (rb.store.get(HighlightingComponent.DO_HIGHLIGHTING) == Boolean.TRUE)

This is verbose... too verbose to my taste. I believe a Store interface can 
help here which provide access to data by a key and will also provide helper 
methods to keep the code clean. (a MapStore can be a simple implementation 
which wraps a Map instance):

{code}
public interface Store {

Boolean getBoolean(String key);
boolean getBoolean(String key, boolean defaultValue);

Integer getInt(String key);
int getInt(String key, int defaultValue);

//other methods for all primitive types and dates.
}
{code}

so now you have:

{code}
if (rb.store.getBoolean(HighlightingComponent.DO_HIGHLIGHTING, false))
{code}

which is cleaner and is NPE-safe.

bq. I believe the public API's should have no dependency on components .
I agree. Basically avoid having circular dependencies. You don't want to change 
the platform API every time you introduce a new component.

  was (Author: uboness):
bq. if (rb.store.get(HighlightingComponent.DO_HIGHLIGHTING) == Boolean.TRUE)

This is verbose... too verbose to my taste. I believe a Store interface can 
help here which provide access to data by a key and will also provide helper 
methods to keep the code clean. (a MapStore can be a simple implementation 
which wraps a Map instance):

{code}
public interface Context {

Boolean getBoolean(String key);
boolean getBoolean(String key, boolean defaultValue);

Integer getInt(String key);
int getInt(String key, int defaultValue);

//other methods for all primitive types and dates.
}
{code}

so now you have:

{code}
if (rb.store.getBoolean(HighlightingComponent.DO_HIGHLIGHTING, false))
{code}

which is cleaner and is NPE-safe.

bq. I believe the public API's should have no dependency on components .
I agree. Basically avoid having circular dependencies. You don't want to change 
the platform API every time you introduce a new component.
  
> Provide a clean way to keep flags and helper objects in ResponseBuilder
> ---
>
> Key: SOLR-1644
> URL: https://issues.apache.org/jira/browse/SOLR-1644
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.5
>
> Attachments: SOLR-1644.patch
>
>
> Many components such as StatsComponent, FacetComponent etc keep flags and 
> helper objects in ResponseBuilder. Having to modify the ResponseBuilder for 
> such things is a very kludgy solution.
> Let us provide a clean way for components to keep arbitrary objects for the 
> duration of a (distributed) search request.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1644) Provide a clean way to keep flags and helper objects in ResponseBuilder

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789919#action_12789919
 ] 

Noble Paul commented on SOLR-1644:
--

bq. if ((Boolean)rb.store.get(HighlightingComponent.DO_HIGHLIGHTING))

This may cause NPE

so it will look like 

if (rb.store.get(HighlightingComponent.DO_HIGHLIGHTING) == Boolean.TRUE)

definitely it looks verbose (ugly) . But the point is where do we stop? Which 
all components qualify to be important enough. Is 'my component' 
more/lessimportant than FacetComponent. If we set a coding standard , isn't 
that better? I believe the public API's  should have no dependency on 
components .

> Provide a clean way to keep flags and helper objects in ResponseBuilder
> ---
>
> Key: SOLR-1644
> URL: https://issues.apache.org/jira/browse/SOLR-1644
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.5
>
> Attachments: SOLR-1644.patch
>
>
> Many components such as StatsComponent, FacetComponent etc keep flags and 
> helper objects in ResponseBuilder. Having to modify the ResponseBuilder for 
> such things is a very kludgy solution.
> Let us provide a clean way for components to keep arbitrary objects for the 
> duration of a (distributed) search request.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1644) Provide a clean way to keep flags and helper objects in ResponseBuilder

[Yonik Seeley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789917#action_12789917
 ] 

Yonik Seeley commented on SOLR-1644:


bq. This one change can keep the ResponseBuilder from being a kitchen sink

But we should do it selectively.  Replacing a bunch of flags with public 
strings that one needs to look up doesn't seem to be an improvement.

if (rb.doHighlighting)
 vs
if ((Boolean)rb.store.get(HighlightingComponent.DO_HIGHLIGHTING))

> Provide a clean way to keep flags and helper objects in ResponseBuilder
> ---
>
> Key: SOLR-1644
> URL: https://issues.apache.org/jira/browse/SOLR-1644
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.5
>
> Attachments: SOLR-1644.patch
>
>
> Many components such as StatsComponent, FacetComponent etc keep flags and 
> helper objects in ResponseBuilder. Having to modify the ResponseBuilder for 
> such things is a very kludgy solution.
> Let us provide a clean way for components to keep arbitrary objects for the 
> duration of a (distributed) search request.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1123) Change the JSONResponseWriter content type

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789916#action_12789916
 ] 

Noble Paul commented on SOLR-1123:
--

SOLR-1516 has the potential to simplify our existing responsewriters . 

> Change the JSONResponseWriter content type
> --
>
> Key: SOLR-1123
> URL: https://issues.apache.org/jira/browse/SOLR-1123
> Project: Solr
>  Issue Type: Improvement
>Reporter: Uri Boness
> Fix For: 1.5
>
> Attachments: JSON_contentType_incl_tests.patch
>
>
> Currently the jSON content type is not used. Instead the palin/text content 
> type is used. The reason for this as I understand is to enable viewing the 
> json response as as text in the browser. While this is valid argument, I do 
> believe that there should at least be an option to configure this writer to 
> use the JSON content type. According to 
> [RFC4627|http://www.ietf.org/rfc/rfc4627.txt] the json content type needs to 
> be application/json (and not text/x-json). The reason this can be very 
> helpful is that today you have plugins for browsers (e.g. 
> [JSONView|http://brh.numbera.com/software/jsonview]) that can render any page 
> with application/json content type in a user friendly manner (just like xml 
> is supported).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1123) Change the JSONResponseWriter content type

[Yonik Seeley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789915#action_12789915
 ] 

Yonik Seeley commented on SOLR-1123:


I never got a chance to check out SOLR-1516, but my understanding was that it 
was a response writer that made it easy for custom response writers to inherit 
from?  I'm not sure we should introduce that as a dependency for the standard 
response writers.

> Change the JSONResponseWriter content type
> --
>
> Key: SOLR-1123
> URL: https://issues.apache.org/jira/browse/SOLR-1123
> Project: Solr
>  Issue Type: Improvement
>Reporter: Uri Boness
> Fix For: 1.5
>
> Attachments: JSON_contentType_incl_tests.patch
>
>
> Currently the jSON content type is not used. Instead the palin/text content 
> type is used. The reason for this as I understand is to enable viewing the 
> json response as as text in the browser. While this is valid argument, I do 
> believe that there should at least be an option to configure this writer to 
> use the JSON content type. According to 
> [RFC4627|http://www.ietf.org/rfc/rfc4627.txt] the json content type needs to 
> be application/json (and not text/x-json). The reason this can be very 
> helpful is that today you have plugins for browsers (e.g. 
> [JSONView|http://brh.numbera.com/software/jsonview]) that can render any page 
> with application/json content type in a user friendly manner (just like xml 
> is supported).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (SOLR-1653) add PatternReplaceCharFilter

[Koji Sekiguchi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Koji Sekiguchi reassigned SOLR-1653:


Assignee: Koji Sekiguchi

> add PatternReplaceCharFilter
> 
>
> Key: SOLR-1653
> URL: https://issues.apache.org/jira/browse/SOLR-1653
> Project: Solr
>  Issue Type: New Feature
>  Components: Schema and Analysis
>Affects Versions: 1.4
>Reporter: Koji Sekiguchi
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1653.patch
>
>
> Add a new CharFilter that uses a regular expression for the target of replace 
> string in char stream.
> Usage:
> {code:title=schema.xml}
>  positionIncrementGap="100" >
>   
>  groupedPattern="([nN][oO]\.)\s*(\d+)"
> replaceGroups="1,2" blockDelimiters=":;"/>
>  mapping="mapping-ISOLatin1Accent.txt"/>
> 
>   
> 
> {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1653) add PatternReplaceCharFilter

[Koji Sekiguchi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Koji Sekiguchi updated SOLR-1653:
-

Attachment: SOLR-1653.patch

> add PatternReplaceCharFilter
> 
>
> Key: SOLR-1653
> URL: https://issues.apache.org/jira/browse/SOLR-1653
> Project: Solr
>  Issue Type: New Feature
>  Components: Schema and Analysis
>Affects Versions: 1.4
>Reporter: Koji Sekiguchi
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1653.patch
>
>
> Add a new CharFilter that uses a regular expression for the target of replace 
> string in char stream.
> Usage:
> {code:title=schema.xml}
>  positionIncrementGap="100" >
>   
>  groupedPattern="([nN][oO]\.)\s*(\d+)"
> replaceGroups="1,2" blockDelimiters=":;"/>
>  mapping="mapping-ISOLatin1Accent.txt"/>
> 
>   
> 
> {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [ANNOUNCEMENT] HttpComponents HttpClient 4.0.1 (GA) Released

[Yonik Seeley]

2009/12/13 Noble Paul നോബിള്‍  नोब्ळ् :
> The point is , the underlying http request is still synchronous (
> correct me if I am wrong) . So there is some thread waiting somewhere
> either the httpclinet framework or the threadpool in solr.

Not if one uses async NIO (which I assume httpclient async uses, but I
don't know for sure).

-Yonik
http://www.lucidimagination.com

[jira] Created: (SOLR-1653) add PatternReplaceCharFilter

[Koji Sekiguchi (JIRA)]

add PatternReplaceCharFilter


 Key: SOLR-1653
 URL: https://issues.apache.org/jira/browse/SOLR-1653
 Project: Solr
  Issue Type: New Feature
  Components: Schema and Analysis
Affects Versions: 1.4
Reporter: Koji Sekiguchi
Priority: Minor
 Fix For: 1.5


Add a new CharFilter that uses a regular expression for the target of replace 
string in char stream.

Usage:
{code:title=schema.xml}

  



  

{code}


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [ANNOUNCEMENT] HttpComponents HttpClient 4.0.1 (GA) Released

[Noble Paul നോബിള്‍ नोब्ळ्]

On Sun, Dec 13, 2009 at 10:14 PM, Yonik Seeley
 wrote:
> 2009/12/13 Noble Paul നോബിള്‍  नोब्ळ् :
>> I guess the async part is done by the client library itself. How does
>> it help Solr?
>
> The only place that makes sense for async in solr is sending multiple
> requests as part of a distributed search (potentially hundreds) and
> not having to have a thread for each.  But even in that case I'm not
> sure it's really a big deal -  for each request, the work required of
> the system as a whole is much greater than the resources a thread
> takes up (and we use a thread pool to avoid creating/destroying
> threads all the time).
The point is , the underlying http request is still synchronous (
correct me if I am wrong) . So there is some thread waiting somewhere
either the httpclinet framework or the threadpool in solr.
>
> -Yonik
> http://www.lucidimagination.com
>



-- 
-
Noble Paul | Systems Architect| AOL | http://aol.com

[jira] Issue Comment Edited: (SOLR-1566) Allow components to add fields to outgoing documents

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789914#action_12789914
 ] 

Noble Paul edited comment on SOLR-1566 at 12/13/09 4:47 PM:


Yeah. SOLR-1298 and this are trying to achieve something in common. It is not 
possible for these 2 issues to have 2 different directions.  

It is not enough to have just function results to be added as values. We should 
be able to add just about anything

  was (Author: noble.paul):
Yeah. SOLR-1298 and this are trying to achieve something in common. It is 
not possible for these 2 issues to have 2 different directions.  
  
> Allow components to add fields to outgoing documents
> 
>
> Key: SOLR-1566
> URL: https://issues.apache.org/jira/browse/SOLR-1566
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Noble Paul
> Fix For: 1.5
>
> Attachments: SOLR-1566.patch, SOLR-1566.patch, SOLR-1566.patch, 
> SOLR-1566.patch
>
>
> Currently it is not possible for components to add fields to outgoing 
> documents which are not in the the stored fields of the document.  This makes 
> it cumbersome to add computed fields/metadata .

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1566) Allow components to add fields to outgoing documents

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789914#action_12789914
 ] 

Noble Paul commented on SOLR-1566:
--

Yeah. SOLR-1298 and this are trying to achieve something in common. It is not 
possible for these 2 issues to have 2 different directions.  

> Allow components to add fields to outgoing documents
> 
>
> Key: SOLR-1566
> URL: https://issues.apache.org/jira/browse/SOLR-1566
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Noble Paul
> Fix For: 1.5
>
> Attachments: SOLR-1566.patch, SOLR-1566.patch, SOLR-1566.patch, 
> SOLR-1566.patch
>
>
> Currently it is not possible for components to add fields to outgoing 
> documents which are not in the the stored fields of the document.  This makes 
> it cumbersome to add computed fields/metadata .

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [ANNOUNCEMENT] HttpComponents HttpClient 4.0.1 (GA) Released

[Yonik Seeley]

2009/12/13 Noble Paul നോബിള്‍  नोब्ळ् :
> I guess the async part is done by the client library itself. How does
> it help Solr?

The only place that makes sense for async in solr is sending multiple
requests as part of a distributed search (potentially hundreds) and
not having to have a thread for each.  But even in that case I'm not
sure it's really a big deal -  for each request, the work required of
the system as a whole is much greater than the resources a thread
takes up (and we use a thread pool to avoid creating/destroying
threads all the time).

-Yonik
http://www.lucidimagination.com

[jira] Commented: (SOLR-1566) Allow components to add fields to outgoing documents

[Grant Ingersoll (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789913#action_12789913
 ] 

Grant Ingersoll commented on SOLR-1566:
---

I think we should try to coordinate w/ SOLR-1298 a bit and take a step back

> Allow components to add fields to outgoing documents
> 
>
> Key: SOLR-1566
> URL: https://issues.apache.org/jira/browse/SOLR-1566
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Noble Paul
> Fix For: 1.5
>
> Attachments: SOLR-1566.patch, SOLR-1566.patch, SOLR-1566.patch, 
> SOLR-1566.patch
>
>
> Currently it is not possible for components to add fields to outgoing 
> documents which are not in the the stored fields of the document.  This makes 
> it cumbersome to add computed fields/metadata .

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1123) Change the JSONResponseWriter content type

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789912#action_12789912
 ] 

Noble Paul commented on SOLR-1123:
--

Should we make responsewriters use the GenericTextResponseWriter SOLR-1516?

> Change the JSONResponseWriter content type
> --
>
> Key: SOLR-1123
> URL: https://issues.apache.org/jira/browse/SOLR-1123
> Project: Solr
>  Issue Type: Improvement
>Reporter: Uri Boness
> Fix For: 1.5
>
> Attachments: JSON_contentType_incl_tests.patch
>
>
> Currently the jSON content type is not used. Instead the palin/text content 
> type is used. The reason for this as I understand is to enable viewing the 
> json response as as text in the browser. While this is valid argument, I do 
> believe that there should at least be an option to configure this writer to 
> use the JSON content type. According to 
> [RFC4627|http://www.ietf.org/rfc/rfc4627.txt] the json content type needs to 
> be application/json (and not text/x-json). The reason this can be very 
> helpful is that today you have plugins for browsers (e.g. 
> [JSONView|http://brh.numbera.com/software/jsonview]) that can render any page 
> with application/json content type in a user friendly manner (just like xml 
> is supported).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [ANNOUNCEMENT] HttpComponents HttpClient 4.0.1 (GA) Released

[Noble Paul നോബിള്‍ नोब्ळ्]

I guess the async part is done by the client library itself. How does
it help Solr?

On Sun, Dec 13, 2009 at 5:55 PM, Uri Boness  wrote:
> I think it would also be wise to have a look at Jetty's httpclient. I think
> its asynchronous nature can play nice for shard requests.
>
> see: http://wiki.eclipse.org/Jetty/Tutorial/HttpClient
>
> Cheers,
> Uri
>
> Grant Ingersoll wrote:
>>
>> In fact, see https://issues.apache.org/jira/browse/SOLR-1429
>>
>> On Dec 11, 2009, at 1:05 PM, Grant Ingersoll wrote:
>>
>>
>>>
>>> There are, in fact, updates to many of Solr's dependencies that we should
>>> consider.  I like the sound of 5-10% perf. improvement in HttpClient...
>>>
>>> -Grant
>>>
>>> On Dec 11, 2009, at 12:53 PM, Erik Hatcher wrote:
>>>
>>>

 FYI...

 Begin forwarded message:


>
> From: Oleg Kalnichevski 
> Date: December 11, 2009 2:20:50 PM GMT+01:00
> To: annou...@apache.org, priv...@hc.apache.org, d...@hc.apache.org,
>  httpclient-us...@hc.apache.org
> Subject: [ANNOUNCEMENT] HttpComponents HttpClient 4.0.1 (GA) Released
> Reply-To: HttpComponents Project 
>
> HttpClient 4.0.1 is a bug fix release that addresses a number of issues
> discovered since the previous stable release. None of the fixed bugs is
> considered critical. Most notably this release eliminates eliminates
> dependency on JCIP annotations.
>
> This release is also expected to improve performance by 5 to 10% due to
> elimination of unnecessary Log object lookups by short-lived components.
>
> ---
> Download -
> 
>
> Release notes -
>
> 
>
> HttpComponents site -
> 
>
> Please note HttpClient 4.0 currently provides only limited support for
> NTLM authentication. For details please refer to
> 
> ---
>
> About Apache HttpClient
>
> Although the java.net package provides basic functionality for
> accessing
> resources via HTTP, it doesn't provide the full flexibility or
> functionality needed by many applications. HttpClient seeks to fill
> this
> void by providing an efficient, up-to-date, and feature-rich package
> implementing the client side of the most recent HTTP standards and
> recommendations.
>
> Designed for extension while providing robust support for the base HTTP
> protocol, HttpClient may be of interest to anyone building HTTP-aware
> client applications such as web browsers, web service clients, or
> systems that leverage or extend the HTTP protocol for distributed
> communication.
>
>
>>>
>>> --
>>> Grant Ingersoll
>>> http://www.lucidimagination.com/
>>>
>>> Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using
>>> Solr/Lucene:
>>> http://www.lucidimagination.com/search
>>>
>>>
>>
>> --
>> Grant Ingersoll
>> http://www.lucidimagination.com/
>>
>> Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using
>> Solr/Lucene:
>> http://www.lucidimagination.com/search
>>
>>
>>
>



-- 
-
Noble Paul | Systems Architect| AOL | http://aol.com

[jira] Commented: (SOLR-1644) Provide a clean way to keep flags and helper objects in ResponseBuilder

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789911#action_12789911
 ] 

Noble Paul commented on SOLR-1644:
--

bq.While we should make it easy for custom components to store their own flags 
+ state, etc, we should be careful about hiding the state of well known 
components

By keeping the key public we ensure that other components can see/change it.

bq.it eliminates a hash lookup for each component each time through the loop

We do 100s of hash lookups in each request. This one change can keep the 
ResponseBuilder from being a kitchen sink and the design cleaner .

bq.Is the plan to have a KEY per component instance? If so, how would it be 
possible to refer to the key from other components?

you are right. We should make it public static. I hope that there aren't 
multiple instances of the same component registered in the same handler
 

> Provide a clean way to keep flags and helper objects in ResponseBuilder
> ---
>
> Key: SOLR-1644
> URL: https://issues.apache.org/jira/browse/SOLR-1644
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.5
>
> Attachments: SOLR-1644.patch
>
>
> Many components such as StatsComponent, FacetComponent etc keep flags and 
> helper objects in ResponseBuilder. Having to modify the ResponseBuilder for 
> such things is a very kludgy solution.
> Let us provide a clean way for components to keep arbitrary objects for the 
> duration of a (distributed) search request.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1298) FunctionQuery results as pseudo-fields

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789909#action_12789909
 ] 

Noble Paul commented on SOLR-1298:
--

bq.perhaps even put it in a separate "meta-data" section under the document

This has been discussed earlier. The meta section is not a clean idea. We 
should put them as normal fields. 

Instead of inventing a new syntax , let us use the local params syntax. we do 
not have to try to have any  similarity with SQL .

> FunctionQuery results as pseudo-fields
> --
>
> Key: SOLR-1298
> URL: https://issues.apache.org/jira/browse/SOLR-1298
> Project: Solr
>  Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1298-FieldValues.patch, SOLR-1298.patch
>
>
> It would be helpful if the results of FunctionQueries could be added as 
> fields to a document. 
> Couple of options here:
> 1. Run FunctionQuery as part of relevance score and add that piece to the 
> document
> 2. Run the function (not really a query) during Document/Field retrieval

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1298) FunctionQuery results as pseudo-fields

[Uri Boness (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789908#action_12789908
 ] 

Uri Boness commented on SOLR-1298:
--

I like the idea of giving the providing a broader context (document, request, 
response). This will also allow them to operate on multiple documents in the 
response (whether it's the docset or the doclist).

One thing to take into consideration here is that one you introduce dependency 
between the fields, there must be a way to determine the ordering of the 
providers (as one provider might depend on fields generated by another 
provider).

as for the " AS " syntax. I think this should be consistent with 
the work in SOLR-1351 which is currently based on localparams. Perhaps there 
should be a common approach to handle aliases in requests.

I think that the proper approach is to separate the stored fields from other 
"fields.. perhaps even put it in a separate "meta-data" section under the 
document. But once you do that, again, for the sake of consistency, it would 
also be wise *not* to include these fields/functions in the "fl" parameter. So 
the "fl" parameter will refer to fields, and another parameter "meta" will 
refer to meta-data values.

bq. fl={!func}foo
+1 or even func:foo. Then you can have things like "url:" or "file:" or even "db:"

> FunctionQuery results as pseudo-fields
> --
>
> Key: SOLR-1298
> URL: https://issues.apache.org/jira/browse/SOLR-1298
> Project: Solr
>  Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1298-FieldValues.patch, SOLR-1298.patch
>
>
> It would be helpful if the results of FunctionQueries could be added as 
> fields to a document. 
> Couple of options here:
> 1. Run FunctionQuery as part of relevance score and add that piece to the 
> document
> 2. Run the function (not really a query) during Document/Field retrieval

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1298) FunctionQuery results as pseudo-fields

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789906#action_12789906
 ] 

Noble Paul commented on SOLR-1298:
--

hi Chris, Yonik,
did you check out SOLR-1566 ?  it is trying to achieve the same thing. It 
provides both streaming as well as pre-computed fields

> FunctionQuery results as pseudo-fields
> --
>
> Key: SOLR-1298
> URL: https://issues.apache.org/jira/browse/SOLR-1298
> Project: Solr
>  Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1298-FieldValues.patch, SOLR-1298.patch
>
>
> It would be helpful if the results of FunctionQueries could be added as 
> fields to a document. 
> Couple of options here:
> 1. Run FunctionQuery as part of relevance score and add that piece to the 
> document
> 2. Run the function (not really a query) during Document/Field retrieval

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1298) FunctionQuery results as pseudo-fields

[Yonik Seeley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789898#action_12789898
 ] 

Yonik Seeley commented on SOLR-1298:


A few comments and random thoughts on this feature in general:
- Think scalability... there should be a way to keep things streamable.  Some 
people will want to retrieve values for many documents (10K, 100K, or their 
whole index).  But of course there should be a way for a component to simply 
add values calculated all at once too.
- For performance, providers of field values should be able to operate on 
multiple documents at once.  For example, providers may want to sort big blocks 
of docids and access in docid order for better performance (important for 
anything that accesses the index).  A value provider that needs to access 
another system would want to send multiple IDs in a batch.
- Field value providers should be given context, including optionally the set 
of fields for the current document, and probably the request and response 
objects
- Perhaps this should be more generalized in that the value provider be a 
document mutator - it should be able to also change or remove other fields.  I 
believe this would also allow stuff like per-field security.  Field value 
providers should also be able to add multiple fields - it may not know ahead of 
time what extra fields a document has.
- should work with highlighting... this way people don't have to store large 
text fields if they already have them in another system.
- keep in mind that some people believe that derived fields (or meta fields) 
don't belong in the same place as other stored fields.  I think it probably 
depends on the exact usecase though.
- I'm not sure if SolrIndexSearcher is the right place for this or not though - 
perhaps its document() method should stick to just the stored fields?
- Think about how to name these fields nicer names... perhaps this could even 
include the "select as" ability to rename fields.
One thought: use an optional '=' or use the "AS" syntax
  fl=foo=bar,dist=gdist(10,20,loc)  or 
  fl=foo AS bar, gdist(10,20,loc) AS dist  (more familiar to DB people?)
Another option for providing names that would only work with queries/function 
queries would be local params:
  fl={!key=dist}gdist(10,20,loc)
but that only works for queries so it's not as flexible
- *If* we use the fl syntax for including function queries, then we should 
consider providing the ability to use multiple "fl" params.  This will make it 
easier for clients who want to tack something on w/o modifying other params.
  If we provide multiple fl params, then an alternate way to specify aliases 
could be:
fl.dist=gdist(10,20,loc)
- fl=foo is ambiguous... do we mean a function query or the field?... perhaps 
if it's a bare field name, then we treat it as a field unless it has 
localparams?
  fl={!func}foo

> FunctionQuery results as pseudo-fields
> --
>
> Key: SOLR-1298
> URL: https://issues.apache.org/jira/browse/SOLR-1298
> Project: Solr
>  Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1298-FieldValues.patch, SOLR-1298.patch
>
>
> It would be helpful if the results of FunctionQueries could be added as 
> fields to a document. 
> Couple of options here:
> 1. Run FunctionQuery as part of relevance score and add that piece to the 
> document
> 2. Run the function (not really a query) during Document/Field retrieval

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1298) FunctionQuery results as pseudo-fields

[Chris Male (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Male updated SOLR-1298:
-

Attachment: SOLR-1298-FieldValues.patch

Attached new patch which changes the names from FieldValueSource to 
FieldValues, and FieldValueSourceRegistry to FieldValuesRegistry, to avoid 
confusion with ValueSource.

> FunctionQuery results as pseudo-fields
> --
>
> Key: SOLR-1298
> URL: https://issues.apache.org/jira/browse/SOLR-1298
> Project: Solr
>  Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1298-FieldValues.patch, SOLR-1298.patch
>
>
> It would be helpful if the results of FunctionQueries could be added as 
> fields to a document. 
> Couple of options here:
> 1. Run FunctionQuery as part of relevance score and add that piece to the 
> document
> 2. Run the function (not really a query) during Document/Field retrieval

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1298) FunctionQuery results as pseudo-fields

[Chris Male (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Male updated SOLR-1298:
-

Attachment: SOLR-1298.patch

Attaching the patch taken from my SOLR-773 patch.  Adds in a FieldValueSource 
and FieldValueSourceRegistry, changes the SolrIndexSearcher to use 
FieldValueSources when building a document, and hooks this process into the 
ReponseWriters.

> FunctionQuery results as pseudo-fields
> --
>
> Key: SOLR-1298
> URL: https://issues.apache.org/jira/browse/SOLR-1298
> Project: Solr
>  Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1298.patch
>
>
> It would be helpful if the results of FunctionQueries could be added as 
> fields to a document. 
> Couple of options here:
> 1. Run FunctionQuery as part of relevance score and add that piece to the 
> document
> 2. Run the function (not really a query) during Document/Field retrieval

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1298) FunctionQuery results as pseudo-fields

[Chris Male (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789891#action_12789891
 ] 

Chris Male commented on SOLR-1298:
--

Hi Uri,

Yup the functions as fl parameters works straight away with the 
FieldValueSource so no changes required there.  I will first chuck up a patch 
without SOLR-1644 so that it can be immediately reviewed, then I'll dive into 
how to update it to 1644 and will create another patch then.

> FunctionQuery results as pseudo-fields
> --
>
> Key: SOLR-1298
> URL: https://issues.apache.org/jira/browse/SOLR-1298
> Project: Solr
>  Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
>
> It would be helpful if the results of FunctionQueries could be added as 
> fields to a document. 
> Couple of options here:
> 1. Run FunctionQuery as part of relevance score and add that piece to the 
> document
> 2. Run the function (not really a query) during Document/Field retrieval

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1298) FunctionQuery results as pseudo-fields

[Uri Boness (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789890#action_12789890
 ] 

Uri Boness commented on SOLR-1298:
--

Chris, another thing. You might want to update the FieldValueSource solution to 
work with SOLR-1644 (instead of the request context)

> FunctionQuery results as pseudo-fields
> --
>
> Key: SOLR-1298
> URL: https://issues.apache.org/jira/browse/SOLR-1298
> Project: Solr
>  Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
>
> It would be helpful if the results of FunctionQueries could be added as 
> fields to a document. 
> Couple of options here:
> 1. Run FunctionQuery as part of relevance score and add that piece to the 
> document
> 2. Run the function (not really a query) during Document/Field retrieval

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1298) FunctionQuery results as pseudo-fields

[Uri Boness (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789889#action_12789889
 ] 

Uri Boness commented on SOLR-1298:
--

{quote}
I certainly can. I hadn't thought about having a function as an fl parameter 
value, but that makes alot of sense and I can support that through my work as 
well. I'll work on extracting the code today and will get a patch here ASAP.
{quote}

As far as I recall the fact the functions are specified in the fl parameter 
should still work with the FieldValueSource as it is at the moment. The 
registry enables you to register any value for any string key, in this case the 
string key is the function.

> FunctionQuery results as pseudo-fields
> --
>
> Key: SOLR-1298
> URL: https://issues.apache.org/jira/browse/SOLR-1298
> Project: Solr
>  Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
>
> It would be helpful if the results of FunctionQueries could be added as 
> fields to a document. 
> Couple of options here:
> 1. Run FunctionQuery as part of relevance score and add that piece to the 
> document
> 2. Run the function (not really a query) during Document/Field retrieval

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1298) FunctionQuery results as pseudo-fields

[Chris Male (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789887#action_12789887
 ] 

Chris Male commented on SOLR-1298:
--

Hi Grant,

I certainly can.  I hadn't thought about having a function as an fl parameter 
value, but that makes alot of sense and I can support that through my work as 
well.  I'll work on extracting the code today and will get a patch here ASAP.

> FunctionQuery results as pseudo-fields
> --
>
> Key: SOLR-1298
> URL: https://issues.apache.org/jira/browse/SOLR-1298
> Project: Solr
>  Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
>
> It would be helpful if the results of FunctionQueries could be added as 
> fields to a document. 
> Couple of options here:
> 1. Run FunctionQuery as part of relevance score and add that piece to the 
> document
> 2. Run the function (not really a query) during Document/Field retrieval

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [ANNOUNCEMENT] HttpComponents HttpClient 4.0.1 (GA) Released

[Uri Boness]

I think it would also be wise to have a look at Jetty's httpclient. I 
think its asynchronous nature can play nice for shard requests.


see: http://wiki.eclipse.org/Jetty/Tutorial/HttpClient

Cheers,
Uri

Grant Ingersoll wrote:

In fact, see https://issues.apache.org/jira/browse/SOLR-1429

On Dec 11, 2009, at 1:05 PM, Grant Ingersoll wrote:

  

There are, in fact, updates to many of Solr's dependencies that we should 
consider.  I like the sound of 5-10% perf. improvement in HttpClient...

-Grant

On Dec 11, 2009, at 12:53 PM, Erik Hatcher wrote:



FYI...

Begin forwarded message:

  

From: Oleg Kalnichevski 
Date: December 11, 2009 2:20:50 PM GMT+01:00
To: annou...@apache.org, priv...@hc.apache.org, d...@hc.apache.org,  
httpclient-us...@hc.apache.org
Subject: [ANNOUNCEMENT] HttpComponents HttpClient 4.0.1 (GA) Released
Reply-To: HttpComponents Project 

HttpClient 4.0.1 is a bug fix release that addresses a number of issues 
discovered since the previous stable release. None of the fixed bugs is 
considered critical. Most notably this release eliminates eliminates dependency 
on JCIP annotations.

This release is also expected to improve performance by 5 to 10% due to 
elimination of unnecessary Log object lookups by short-lived components.

---
Download -


Release notes -


HttpComponents site -


Please note HttpClient 4.0 currently provides only limited support for
NTLM authentication. For details please refer to

---

About Apache HttpClient

Although the java.net package provides basic functionality for accessing
resources via HTTP, it doesn't provide the full flexibility or
functionality needed by many applications. HttpClient seeks to fill this
void by providing an efficient, up-to-date, and feature-rich package
implementing the client side of the most recent HTTP standards and
recommendations.

Designed for extension while providing robust support for the base HTTP
protocol, HttpClient may be of interest to anyone building HTTP-aware
client applications such as web browsers, web service clients, or
systems that leverage or extend the HTTP protocol for distributed
communication.



--
Grant Ingersoll
http://www.lucidimagination.com/

Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using 
Solr/Lucene:
http://www.lucidimagination.com/search




--
Grant Ingersoll
http://www.lucidimagination.com/

Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using 
Solr/Lucene:
http://www.lucidimagination.com/search


  

[jira] Commented: (SOLR-1649) Refactor all ResponseWriters to be more extension-friendly

[Uri Boness (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789884#action_12789884
 ] 

Uri Boness commented on SOLR-1649:
--

I think the class hierarchy needs to change. see: 
https://issues.apache.org/jira/browse/SOLR-1123?focusedCommentId=12711133&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12711133

> Refactor all ResponseWriters to be more extension-friendly
> --
>
> Key: SOLR-1649
> URL: https://issues.apache.org/jira/browse/SOLR-1649
> Project: Solr
>  Issue Type: Improvement
>  Components: Response Writers
>Affects Versions: 1.4
> Environment: My local MacBook pro over the Christmas break.
>Reporter: Chris A. Mattmann
> Fix For: 1.5
>
>
> I'd like to refactor all the ResponseWriters to be a bit less brittle. 
> ResponseWriters should follow a standard interface with more existing methods 
> than is currently present in the interface, and with lots of refactored 
> utility code and more concrete control/data flow. I'll take a hard look at 
> the existing response writers and try to generalize.
> See this thread for background:
> http://www.lucidimagination.com/search/document/e8bb6cac84c1f520/namespaces_in_response_solr_1586#cc50ba9e9d8fe2dc

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1131) Allow a single field type to index multiple fields

[Grant Ingersoll (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Grant Ingersoll updated SOLR-1131:
--

Attachment: SOLR-1131.patch

Added Chris's comments.

> Allow a single field type to index multiple fields
> --
>
> Key: SOLR-1131
> URL: https://issues.apache.org/jira/browse/SOLR-1131
> Project: Solr
>  Issue Type: New Feature
>  Components: Schema and Analysis
>Reporter: Ryan McKinley
>Assignee: Grant Ingersoll
> Fix For: 1.5
>
> Attachments: SOLR-1131-IndexMultipleFields.patch, 
> SOLR-1131.Mattmann.121009.patch.txt, SOLR-1131.Mattmann.121109.patch.txt, 
> SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
> SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
> SOLR-1131.patch
>
>
> In a few special cases, it makes sense for a single "field" (the concept) to 
> be indexed as a set of Fields (lucene Field).  Consider SOLR-773.  The 
> concept "point" may be best indexed in a variety of ways:
>  * geohash (sincle lucene field)
>  * lat field, lon field (two double fields)
>  * cartesian tiers (a series of fields with tokens to say if it exists within 
> that region)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (SOLR-1139) SolrJ TermsComponent Query and Response Support

[Shalin Shekhar Mangar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shalin Shekhar Mangar resolved SOLR-1139.
-

   Resolution: Fixed
Fix Version/s: 1.5

Committed revision 890053.

Thanks Matt!

> SolrJ TermsComponent Query and Response Support
> ---
>
> Key: SOLR-1139
> URL: https://issues.apache.org/jira/browse/SOLR-1139
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java
>Affects Versions: 1.4
>Reporter: Matt Weber
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1139-WITH_SORT_SUPPORT.patch, SOLR-1139.patch, 
> SOLR-1139.patch, SOLR-1139.patch, SOLR-1139.patch, SOLR-1139.patch, 
> SOLR-1139.patch, SOLR-1139.patch
>
>
> SolrJ should support the new TermsComponent that was introduced in Solr 1.4.  
> It should be able to:
> - set TermsComponent query parameters via SolrQuery
> - parse the TermsComponent response

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1139) SolrJ TermsComponent Query and Response Support

[Shalin Shekhar Mangar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shalin Shekhar Mangar updated SOLR-1139:


Attachment: SOLR-1139.patch

Updated patch for two params added by SOLR-1625.

I'll commit this shortly.

> SolrJ TermsComponent Query and Response Support
> ---
>
> Key: SOLR-1139
> URL: https://issues.apache.org/jira/browse/SOLR-1139
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java
>Affects Versions: 1.4
>Reporter: Matt Weber
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Attachments: SOLR-1139-WITH_SORT_SUPPORT.patch, SOLR-1139.patch, 
> SOLR-1139.patch, SOLR-1139.patch, SOLR-1139.patch, SOLR-1139.patch, 
> SOLR-1139.patch, SOLR-1139.patch
>
>
> SolrJ should support the new TermsComponent that was introduced in Solr 1.4.  
> It should be able to:
> - set TermsComponent query parameters via SolrQuery
> - parse the TermsComponent response

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (SOLR-445) XmlUpdateRequestHandler bad documents mid batch aborts rest of batch

[Grant Ingersoll (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Grant Ingersoll reassigned SOLR-445:


Assignee: (was: Grant Ingersoll)

> XmlUpdateRequestHandler bad documents mid batch aborts rest of batch
> 
>
> Key: SOLR-445
> URL: https://issues.apache.org/jira/browse/SOLR-445
> Project: Solr
>  Issue Type: Bug
>  Components: update
>Affects Versions: 1.3
>Reporter: Will Johnson
> Fix For: 1.5
>
>
> Has anyone run into the problem of handling bad documents / failures mid 
> batch.  Ie:
> 
>   
> 1
>   
>   
> 2
> I_AM_A_BAD_DATE
>   
>   
> 3
>   
> 
> Right now solr adds the first doc and then aborts.  It would seem like it 
> should either fail the entire batch or log a message/return a code and then 
> continue on to add doc 3.  Option 1 would seem to be much harder to 
> accomplish and possibly require more memory while Option 2 would require more 
> information to come back from the API.  I'm about to dig into this but I 
> thought I'd ask to see if anyone had any suggestions, thoughts or comments.   
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (SOLR-1298) FunctionQuery results as pseudo-fields

[Grant Ingersoll (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Grant Ingersoll reassigned SOLR-1298:
-

Assignee: Grant Ingersoll

> FunctionQuery results as pseudo-fields
> --
>
> Key: SOLR-1298
> URL: https://issues.apache.org/jira/browse/SOLR-1298
> Project: Solr
>  Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
>
> It would be helpful if the results of FunctionQueries could be added as 
> fields to a document. 
> Couple of options here:
> 1. Run FunctionQuery as part of relevance score and add that piece to the 
> document
> 2. Run the function (not really a query) during Document/Field retrieval

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [ANNOUNCEMENT] HttpComponents HttpClient 4.0.1 (GA) Released

[Grant Ingersoll]

In fact, see https://issues.apache.org/jira/browse/SOLR-1429

On Dec 11, 2009, at 1:05 PM, Grant Ingersoll wrote:

> There are, in fact, updates to many of Solr's dependencies that we should 
> consider.  I like the sound of 5-10% perf. improvement in HttpClient...
> 
> -Grant
> 
> On Dec 11, 2009, at 12:53 PM, Erik Hatcher wrote:
> 
>> FYI...
>> 
>> Begin forwarded message:
>> 
>>> From: Oleg Kalnichevski 
>>> Date: December 11, 2009 2:20:50 PM GMT+01:00
>>> To: annou...@apache.org, priv...@hc.apache.org, d...@hc.apache.org,  
>>> httpclient-us...@hc.apache.org
>>> Subject: [ANNOUNCEMENT] HttpComponents HttpClient 4.0.1 (GA) Released
>>> Reply-To: HttpComponents Project 
>>> 
>>> HttpClient 4.0.1 is a bug fix release that addresses a number of issues 
>>> discovered since the previous stable release. None of the fixed bugs is 
>>> considered critical. Most notably this release eliminates eliminates 
>>> dependency on JCIP annotations.
>>> 
>>> This release is also expected to improve performance by 5 to 10% due to 
>>> elimination of unnecessary Log object lookups by short-lived components.
>>> 
>>> ---
>>> Download -
>>> 
>>> 
>>> Release notes -
>>> 
>>> 
>>> HttpComponents site -
>>> 
>>> 
>>> Please note HttpClient 4.0 currently provides only limited support for
>>> NTLM authentication. For details please refer to
>>> 
>>> ---
>>> 
>>> About Apache HttpClient
>>> 
>>> Although the java.net package provides basic functionality for accessing
>>> resources via HTTP, it doesn't provide the full flexibility or
>>> functionality needed by many applications. HttpClient seeks to fill this
>>> void by providing an efficient, up-to-date, and feature-rich package
>>> implementing the client side of the most recent HTTP standards and
>>> recommendations.
>>> 
>>> Designed for extension while providing robust support for the base HTTP
>>> protocol, HttpClient may be of interest to anyone building HTTP-aware
>>> client applications such as web browsers, web service clients, or
>>> systems that leverage or extend the HTTP protocol for distributed
>>> communication.
>>> 
>> 
> 
> --
> Grant Ingersoll
> http://www.lucidimagination.com/
> 
> Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using 
> Solr/Lucene:
> http://www.lucidimagination.com/search
> 

--
Grant Ingersoll
http://www.lucidimagination.com/

Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using 
Solr/Lucene:
http://www.lucidimagination.com/search

[jira] Commented: (SOLR-1298) FunctionQuery results as pseudo-fields

[Grant Ingersoll (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789880#action_12789880
 ] 

Grant Ingersoll commented on SOLR-1298:
---

Chris, could you isolate this particular part of your patch from SOLR-773?

> FunctionQuery results as pseudo-fields
> --
>
> Key: SOLR-1298
> URL: https://issues.apache.org/jira/browse/SOLR-1298
> Project: Solr
>  Issue Type: New Feature
>Reporter: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
>
> It would be helpful if the results of FunctionQueries could be added as 
> fields to a document. 
> Couple of options here:
> 1. Run FunctionQuery as part of relevance score and add that piece to the 
> document
> 2. Run the function (not really a query) during Document/Field retrieval

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1298) FunctionQuery results as pseudo-fields

[Grant Ingersoll (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789879#action_12789879
 ] 

Grant Ingersoll commented on SOLR-1298:
---

bq. we should also let search components add extra fields to the document. 

I think we could handle this via the ResponseBuilder by storing an > pairing in a map that the ResponseWriter could then consult when it 
needs it as it's streaming out the results.  Tricky part is what to do when 
there are no ids, I suppose.

> FunctionQuery results as pseudo-fields
> --
>
> Key: SOLR-1298
> URL: https://issues.apache.org/jira/browse/SOLR-1298
> Project: Solr
>  Issue Type: New Feature
>Reporter: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
>
> It would be helpful if the results of FunctionQueries could be added as 
> fields to a document. 
> Couple of options here:
> 1. Run FunctionQuery as part of relevance score and add that piece to the 
> document
> 2. Run the function (not really a query) during Document/Field retrieval

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1298) FunctionQuery results as pseudo-fields

[Grant Ingersoll (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789878#action_12789878
 ] 

Grant Ingersoll commented on SOLR-1298:
---

Dang, you know it's bad when you wake up in the morning and the first thing 
that comes into your head is what the interface should look like for some new 
feature in Solr.  

Alas, having just finished SOLR-1297, I think we should simply make the &fl 
parameter be able to parse functions and, if need be, they can be 
materialized/executed as they are being retrieved by the Writer (using 
SOLR-1650 if implemented).

Thus, the interface for this would be:
{code}
&fl=sum(x, y),id,a,b,c,score
{code}
or
{code}
&fl=id,sum(x, y),score
{code}
{code}
&fl=*,sum(x, y),score
{code}

So, the output would be:
{code}
...
foo
40
0.343
...
{code}



> FunctionQuery results as pseudo-fields
> --
>
> Key: SOLR-1298
> URL: https://issues.apache.org/jira/browse/SOLR-1298
> Project: Solr
>  Issue Type: New Feature
>Reporter: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
>
> It would be helpful if the results of FunctionQueries could be added as 
> fields to a document. 
> Couple of options here:
> 1. Run FunctionQuery as part of relevance score and add that piece to the 
> document
> 2. Run the function (not really a query) during Document/Field retrieval

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: SOLR-1131: disconnect between fields created by poly fields

[Grant Ingersoll]

On Dec 12, 2009, at 12:08 AM, 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 secret fields would have made my head explode
> that much louder.

Just as with any dynamic field, the Luke and the LukeRequestHandler are your 
friends.  Which reminds me, I need to mod the patch to have Luke spit out that 
it is a poly field.

I think the thing that is tricky here, is we are actually introducing a new 
layer of processing on top of Lucene that allows for more complex modeling by 
doing away with the notion that there is a 1-1 relationship between a FieldType 
and a Field.  Some people want explicit control, while others won't care about 
the details.


> 
> On Fri, Dec 11, 2009 at 7:01 AM, Yonik Seeley
>  wrote:
>> On Fri, Dec 11, 2009 at 9:53 AM, Mattmann, Chris A (388J)
>>  wrote:
>>> Actually if it was the case that poly field mapped to a single dynamic
>>> field, then I would agree with you, but as is the discussion, poly field can
>>> map to _many_ dynamic fields, which is where the drift occurs.
>> 
>> I'm not sure if we're using the exact same terminology, but it's well
>> defined how many dynamic fields would be created by the basic point
>> class (exactly one) *if* we decide to go that route and use that
>> option.  Can you give an examples of what you mean?  Is your objection
>> to this point class registering a single dynamic field, or are you
>> talking about a hypothetical case?
>> 
>> -Yonik
>> http://www.lucidimagination.com
>> 
> 
> 
> 
> -- 
> Lance Norskog
> goks...@gmail.com