Re: about boost weight

[Norberto Meijome]

On Sat, 13 Sep 2008 16:17:12 +
zzh <[EMAIL PROTECTED]> wrote:

>I think this is a stupid method, because the search conditions is too
> long, and the search efficiency will be low, we hope you can help me to solve
> this problem.

Hi,
IMHO,a long set of conditions doesn't make it stupid. You may not be going the
best way about it though. You may find
http://wiki.apache.org/solr/DisMaxRequestHandler an interesting and useful
read :)

B
_
{Beto|Norberto|Numard} Meijome

"Quality is never an accident, it is always the result of intelligent effort."
  John Ruskin  (1819-1900)

I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.

SolrJ and JSON in Solr -1.3

[Julio Castillo]

What is the status of JSON support via SolrJ?

I want to be able to specify a parser such as the XMLResponseParser on my
SolrServer. What are my options?
I guess I could get an XML response and then convert it to JSON? I rather
not.

There is a JIRA entry SOLR-402, but real resolution to it per the comments
that follow in the feature request.
https://issues.apache.org/jira/browse/SOLR-402


Julio Castillo
Edgenuity Inc.

Is Solr suitable for my application?

[Sergey Nikitin]

Hello everyone,

In our web app we got about 10 million of documents, structure of document
is (only what is important for searching):
~10 Short fields (20 chars max)
1 Long field - represents content of the document, stored as xml. On average
about 50k chars in xml, with about 500 chars of important text data to be
indexed.

Updating/creating of document is a frequent operation, deleting is not
frequent.

Now we are using indexing functionality of our DBMS and it is not as good as
we want (slow, depend on concrete DBMS, additional load on DBMS, not
scalable, etc). So, we want to switch to some other solution.

Most important requirements are: 
functionality - searching by attribute / all attributes, filters, sorting,
synonyms, etc...
performance - at least faster that current solution.
scalability - data and load may grow up, there should be easy way to support
it.

Preferable tradeoffs: 
+ faster queries
- less frequent update (flushing changes once per 24 hours is ok)
- bigger index size

It seems that Solr fits perfectly - a lot of cool features, fast, good
scaling support.
 
Maybe I've missed something important?

Any suggestions would be appreciated.
Thanks,
Sergey
-- 
View this message in context: 
http://www.nabble.com/Is-Solr-suitable-for-my-application--tp19484366p19484366.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: SolrJ and JSON in Solr -1.3

[Erik Hatcher]

On Sep 14, 2008, at 2:51 PM, Julio Castillo wrote:

What is the status of JSON support via SolrJ?


Requires a custom ResponseParser.  See SOLR-402 for a couple of  
implementation ideas:


  

Maybe this code is no longer current to trunk?

I want to be able to specify a parser such as the XMLResponseParser  
on my

SolrServer. What are my options?


Use SolrServer#setParser() for one of the above implementations.

I guess I could get an XML response and then convert it to JSON? I  
rather

not.


Ewww, don't do that.

There is a JIRA entry SOLR-402, but real resolution to it per the  
comments

that follow in the feature request.
https://issues.apache.org/jira/browse/SOLR-402


Did the RawResponseParser work for you?   If so, we can build that  
into Solr trunk - +1.  I shoulda done that a while ago, sorry.  This  
actually fits well with SOLR-620, in my nefarious plans to build a web  
framework out of Solr ;)


Erik

Re: SolrJ and JSON in Solr -1.3

[Erik Hatcher]

If the client wants JSON, then it seems passing it straight from Solr  
through the application server tier (hypothetical architecture here)  
to the client as JSON is a nice way to go.  If the client can talk  
directly to Solr, then definitely just &wt=json and carry on, but more  
often then not an application server is in the middle.


Curious: SolrJ with javabin format to an app server that converts to  
JSON, pros/cons to the raw response writer?


What are others doing in the Ajaxed client world with Solr?

Erik



On Sep 15, 2008, at 12:01 AM, Jon Baer wrote:

Hmm am I missing something but isn't the real point of SolrJ to be  
able to use the binary (javabin) format to keep it small / tight /  
compressed?  I have had to proxy Solr recently and found just  
throwing a SolrDocumentList as a JSONArray (via json.org libs) works  
pretty well (YMMV).  I was just under the impression that the Java  
to Java bridge was the best way to go ...


It would be nice to have util methods on the SolrDocumentList  
(toJSON(), toXML(), etc) maybe?


- Jon

On Sep 14, 2008, at 11:14 PM, Erik Hatcher wrote:



On Sep 14, 2008, at 2:51 PM, Julio Castillo wrote:

What is the status of JSON support via SolrJ?


Requires a custom ResponseParser.  See SOLR-402 for a couple of  
implementation ideas:




Maybe this code is no longer current to trunk?

I want to be able to specify a parser such as the  
XMLResponseParser on my

SolrServer. What are my options?


Use SolrServer#setParser() for one of the above implementations.

I guess I could get an XML response and then convert it to JSON? I  
rather

not.


Ewww, don't do that.

There is a JIRA entry SOLR-402, but real resolution to it per the  
comments

that follow in the feature request.
https://issues.apache.org/jira/browse/SOLR-402


Did the RawResponseParser work for you?   If so, we can build that  
into Solr trunk - +1.  I shoulda done that a while ago, sorry.   
This actually fits well with SOLR-620, in my nefarious plans to  
build a web framework out of Solr ;)


Erik

Sending queries to multicore installation

[Rogerio Pereira]

Hi!

I have a multicore installation with the following configuration:


  






  


Each core uses different schemas, I indexed some docs shopping core and a
few others on tourism core, when I send a query "a*" to tourism core I'm
getting docs from shopping core, this is the expected behaviour? Should I
define a "core" field on both schemas and use this field as filter, like we
have 
here,
to avoid it?

-- 
Regards,

Rogério (_rogerio_)

[Blog: http://faces.eti.br] [Sandbox: http://bmobile.dyndns.org] [Twitter:
http://twitter.com/ararog]

"Faça a diferença! Ajude o seu país a crescer, não retenha conhecimento,
distribua e aprenda mais."
(http://faces.eti.br/2006/10/30/conhecimento-e-amadurecimento)

Re: SolrJ and JSON in Solr -1.3

[Jon Baer]

Hmm am I missing something but isn't the real point of SolrJ to be  
able to use the binary (javabin) format to keep it small / tight /  
compressed?  I have had to proxy Solr recently and found just throwing  
a SolrDocumentList as a JSONArray (via json.org libs) works pretty  
well (YMMV).  I was just under the impression that the Java to Java  
bridge was the best way to go ...


It would be nice to have util methods on the SolrDocumentList  
(toJSON(), toXML(), etc) maybe?


- Jon

On Sep 14, 2008, at 11:14 PM, Erik Hatcher wrote:



On Sep 14, 2008, at 2:51 PM, Julio Castillo wrote:

What is the status of JSON support via SolrJ?


Requires a custom ResponseParser.  See SOLR-402 for a couple of  
implementation ideas:


 

Maybe this code is no longer current to trunk?

I want to be able to specify a parser such as the XMLResponseParser  
on my

SolrServer. What are my options?


Use SolrServer#setParser() for one of the above implementations.

I guess I could get an XML response and then convert it to JSON? I  
rather

not.


Ewww, don't do that.

There is a JIRA entry SOLR-402, but real resolution to it per the  
comments

that follow in the feature request.
https://issues.apache.org/jira/browse/SOLR-402


Did the RawResponseParser work for you?   If so, we can build that  
into Solr trunk - +1.  I shoulda done that a while ago, sorry.  This  
actually fits well with SOLR-620, in my nefarious plans to build a  
web framework out of Solr ;)


Erik

Re: Is Solr suitable for my application?

[Otis Gospodnetic]

Sergey, I don't think you missed anything (unless you count a number of nice 
features that Solr has that you didn't explicitly list) - Solr indeed sounds 
like a good fit.

Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch



- Original Message 
> From: Sergey Nikitin <[EMAIL PROTECTED]>
> To: solr-user@lucene.apache.org
> Sent: Sunday, September 14, 2008 5:07:27 PM
> Subject: Is Solr suitable for my application?
> 
> 
> Hello everyone,
> 
> In our web app we got about 10 million of documents, structure of document
> is (only what is important for searching):
> ~10 Short fields (20 chars max)
> 1 Long field - represents content of the document, stored as xml. On average
> about 50k chars in xml, with about 500 chars of important text data to be
> indexed.
> 
> Updating/creating of document is a frequent operation, deleting is not
> frequent.
> 
> Now we are using indexing functionality of our DBMS and it is not as good as
> we want (slow, depend on concrete DBMS, additional load on DBMS, not
> scalable, etc). So, we want to switch to some other solution.
> 
> Most important requirements are: 
> functionality - searching by attribute / all attributes, filters, sorting,
> synonyms, etc...
> performance - at least faster that current solution.
> scalability - data and load may grow up, there should be easy way to support
> it.
> 
> Preferable tradeoffs: 
> + faster queries
> - less frequent update (flushing changes once per 24 hours is ok)
> - bigger index size
> 
> It seems that Solr fits perfectly - a lot of cool features, fast, good
> scaling support.
> 
> Maybe I've missed something important?
> 
> Any suggestions would be appreciated.
> Thanks,
> Sergey
> -- 
> View this message in context: 
> http://www.nabble.com/Is-Solr-suitable-for-my-application--tp19484366p19484366.html
> Sent from the Solr - User mailing list archive at Nabble.com.