Did DIH support for invoking procedures? if it supported, how to configure it? I can't find it in wiki.
Sort of. You have to write your own custom transformer, see http://wiki.apache.org/solr/DIHCustomTransformer
Related
I am using the scalikejdbc library to access my Postgres database. The driver I am using is the default org.postgresql.Driver. I am trying to introduce query/result caching but I cannot find any evidence whether scalalike does this by default or if it even supports this. I skimmed through the TypesafeConfigReader class but could not find any configuration property indicative of such a functionality. My last resort would be to implement a simple application level cache but I want to know if this is supported somehow by default. In their official docs I could not find something definitive either.
The question was answered in the scalikejdbc issue tracker. So I'm quoting
There is no built-in query cache/result support at this moment. I would suggest using a different cache library such as https://github.com/cb372/scalacache to reduce method calls.
I saw there was a article in the Apache wiki on OpenNLP for Solr.
Is it valid for current solr version 5.3.1?
No, if you have a look at LUCENE-2899, you'll see that the code discussed was never added to trunk. You'll have to download/patch/update the code yourself if you're going to have it native to Solr.
It's probably a better idea to do all the NLP stuff outside of Solr, then index the result in a form suited for the task you're trying to solve.
Yes. It's better to keep it outside.
Here is a small project I tried.
https://github.com/john77eipe/DeepQA
ElasticSearch has percolator for prospective search. Does SOLR have a similar feature where you define your query upfront? If not, is there an effective way of implementing this myself on top of the existing SOLR features?
besides what BunkerMentality said, it is not hard to build your own percolator, what you need:
Are the queries you want to run easy to model on Lucene only syntax? if so you are good, if not, you need to convert them to Lucene only. Built them, and keep them in memory as Lucene queries
When a doc arrives:
build a MemoryIndex containing only that single doc
run all your queries on the index
I have done this for a system ingesting millions docs a day and it worked fine.
It's listed as an open new feature, SOLR-4587, on Solr JIRA but it doesn't seem like any work has started on it yet.
There is a link in the comments there to a separate project called Luwak that seems to implement some features similar to percolator.
If it is still relevant, you can use this
It's SOLR Update Processor that based on Luwak
Is there any geospatial support available for OrientDB (wether its included or from 3rd party vendors)?
In particular I need the ability to build spatial-indexes on my geo-data.
Since SBTree supports range queries, as I understand it, you could efficiently use the distance() function.
Sources:
https://github.com/orientechnologies/orientdb/wiki/SQL-Where#wiki-functions
https://github.com/orientechnologies/orientdb/wiki/Indexes
https://code.google.com/p/orient/source/browse/trunk/tests/src/test/java/com/orientechnologies/orient/test/database/auto/GEOTest.java
Is Lucene Spatial index you are looking for? See the documentation:
https://github.com/orientechnologies/orientdb-lucene/wiki/Spatial-Index
I think the title is self-explanatory.
I don't see anything on the Apache Solr wiki that suggests you can maintain the schema of an Apache Solr instance using the ReST API, but maybe (hopefully) you know something I don't.
I just found a section on the Solr wiki where they describe this exact feature for release 4.4 (which is not released yet).
It does have some prerequisite configuration on the Solr instance, but it does allow you to add fields to the schema. Based on that information, I can't see why they won't eventually extend the functionality to allow you to delete as well. I guess we will have to wait and see.
Here is the link to that section: http://wiki.apache.org/solr/SchemaRESTAPI#Adding_fields_to_a_schema. It also references this JIRA issue: "In preparation for dynamic schema modification via REST API, add a "managed" schema facility".