GithubHelp home page GithubHelp logo

basho / riak_search Goto Github PK

View Code? Open in Web Editor NEW
141.0 141.0 51.0 27.55 MB

Full-text search engine based on Riak

License: Apache License 2.0

Makefile 1.22% Erlang 98.14% Emacs Lisp 0.30% Shell 0.27% Perl 0.07%

riak_search's Introduction

THIS REPO IS DEPRECATED AND NOT UNDER ACTIVE DEVELOPMENT

Overview

Travis-CI :: https://secure.travis-ci.org/basho/riak_search.png

The riak_search OTP application provides https://github.com/basho/riak with the capability to act as a text search engine similar to Apache’s Lucene. Previously Riak Search was a release in it’s own right. Since then Basho has decided it would be easier for our users if Search was simply a set of functionality that can be enabled via a config option. For that reason, if you want to use Search you’ll have to build a Riak release and enable it.

Enabling Search

In order to enable the riak_search app in your Riak cluster you have to modify the etc/app.config file. Search for the text riak_search and then change {enabled, false} to {enabled, true}. The Search portion of your app.config will look something like this.

{riak_search, [
               {enabled, true},
              ]},

riak_search's People

Contributors

argv0 avatar bearcage avatar beerriot avatar bsparrow435 avatar cmeiklejohn avatar coderoshi avatar dizzyd avatar dreverri avatar engelsanchez avatar fadushin avatar gpascale avatar jaredmorrow avatar jburwell avatar jrwest avatar jtuple avatar kellymclaughlin avatar lemenkov avatar lordnull avatar nickelization avatar russelldb avatar rustyio avatar rzezeski avatar seancribbs avatar slfritchie avatar tburghart avatar ulfnorell avatar uwiger avatar vagabond avatar vinoski avatar zeeshanlakhani avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

riak_search's Issues

sort by number?

Using the search interface, I've been unable to figure out how to sort by numerical magnitude rather than alphabetically.

i.e. currently "69" sorts before "7"

Riak Search for Java Client API

The Riak Java Client API does not support querying of Riak Search. but currently , the Ruby, Python, PHP, and Erlang clients are supported. Do you have any road map for the Java Client to support Riak Search.

Regards,
Jagan

when accessing solr search through protocol buffers, 'sort' parameter is ignored

As the code below demonstrates, the 'sort' parameter is ignored when searching via the solr interface with a protocol buffers client. It works fine with the HTTP client.

This may also be a bug in the python client.

import riak
http_client = riak.RiakClient()
pbc_client = riak.RiakClient(port=8087, transport_class=riak.RiakPbcTransport)
bucket = http_client.bucket('test')
bucket.enable_search()

data = {
    'key1': { 'param': 'a' },
    'key2': { 'param': 'c' },
    'key3': { 'param': 'b' }
}

for k, v in data.items():
    obj = bucket.new(k,v)
    obj.store()

print "--- sorted by param (expect a,b,c)"
print "HTTP result (gives a,b,c):"
result = http_client.solr().search('test', 'param:[a TO z]', sort='param', rows=20)
for doc in result['docs']: 
    print doc

print "PBC result (gives a,c,b):"
result = pbc_client.solr().search('test', 'param:[a TO z]', sort='param', rows=20)
for doc in result['docs']: 
    print doc

Which version's solr(lucene) grammar is riak 2.0 search going to support?

I'm planning to test out migrating riak 1.4 to riak 2.0 test version, in introduce page I saw it seems support all solr dialects, so I'm interested at which version does it supports right now, since solr 4.0 it starts to support regular expression on search(http://stackoverflow.com/questions/9332343/what-regular-expression-features-are-supported-by-solr-edismax), and I've took a glance at source code seems currently only it does compile regular expression based on wildcard, is there any possibility to enable this feature?

Curl update does not work on allow_mult: false, map bucket type

Solr is creating a new document for each update of the same riak document.

Steps to repro:

  • turn on search
  • start up riak
  • create index: curl -XPUT $RIAK_HOST/search/index/master -H 'Content-Type: application/json'
  • associate index: curl -XPUT $RIAK_HOST/buckets/master/props -H 'Content-Type: application/json' -d '{"props":{"search_index":"master"}}'
  • add a document: curl -XPUT $RIAK_HOST/buckets/master/keys/TF6sXjwTZNAX9CZKiS2NaSA12PG -d '{ "test": 1 }' -H 'content-type: application/json'
  • check solr: curl "$RIAK_HOST/search/query/master?q=:&wt=json"
  • notice there is one doc
  • update the document: curl -XPUT $RIAK_HOST/buckets/master/keys/TF6sXjwTZNAX9CZKiS2NaSA12PG -d '{ "test": 1 }' -H 'content-type: application/json'
  • check solr again

Expected Results:
should only be one solr document

Actual:
two solr documents.

There is no way to change the uniqueKey to something other than _yz_id, which I think would solve this problem since _yz_id is different for each.

performance issues: PB client/mapred/pipe

As pointed out on the mailing list there are performance issues regarding the integration of the PB client/pipe/mapred/search (1). Essentially mapred/search can take orders of magnitude longer via the PB client because of issues with pipe/search integration. Until this is fixed there are two work arounds:

  1. Use legacy mapreduce (2)
  2. If writing an Erlang application you can still use pipe for mapreduce but make rpc calls to the search:mapred function. This function is still hardcoded to use the legacy system and therefore won't be affected if the general mapreduce system is using pipe.

1: http://lists.basho.com/pipermail/riak-users_lists.basho.com/2012-April/008050.html

2: https://wiki.basho.com/Configuration-Files.html#mapred_system

Unable to get search schema to be applied

Hi

I am not sure if I am doing something incorrectly or not. I am trying to specify fields as exact string match using a custom schema. My schema is not being applied. If I append _dt to my field I am able to use the noop analyzer which gives me the intended behavior. However, I do not want to use a suffix on all my string fields. Here is my schema file I am trying to use.

{
schema,
[
{version, "1.1"},
{default_field, "text"},
{default_op, "or"},
{n_val, 3},
{analyzer_factory, {erlang, text_analyzers, noop_analyzer_factory}}
],
[
%% Parse the field in preparation for full-text searching.
{field, [
{name, "NewQueueId"},
{type, string},
{analyzer_factory, {erlang, text_analyzers, noop_analyzer_factory}}
]},

    %% A dynamic field. Catches any remaining fields in the
    %% document, and uses the analyzer_factory setting defined
    %% above for the schema.
    {dynamic_field, [
        {name, "*"}
    ]}
]

}.

I am inserting json that looks like this...

{
"Id": "96ac9a6c-d170-4e29-a81b-dee048e6a3d1",
"QueueRulesId": 102,
"Status": 77,
"Assigned": 99,
"Stream": {
"ID": "4753afec-ba8b-4656-a216-7ff1f25dc82f",
"Status": "NEW"
},
"Queue": 1,
"Action": "Create",
"NewStatusId": "12",
"NewQueueId": "5678 Test",
"KeepAssigned": "12",
"MetaData": [],
"Date": "2013-01-30-05T13:15:30Z"
}

I am performing a search of NewQueueId:5678 and am still getting this record back. I am only wanting to match on 5678 and not 5678 Test. Any help is greatly appreciated.

Thanks,
Jared

KV Hook Fails with `badarg` if Search is not Enabled

If you manage to install the Search KV hook when search is disabled, PUTs to that bucket fail with an uninformative badarg:

1> C:set_bucket(<<"mine">>, [{precommit, [{struct,[{<<"mod">>,<<"riak_search_kv_hook">>},{<<"fun">>,<<"precommit">>}]}]}]).
ok
6> C:put(riak_object:new(<<"mine">>, <<"two">>, <<"foobar">>)).
{error,
    {precommit_fail,
        {hook_crashed,
            {riak_search_kv_hook,precommit,error,badarg}}}}

The badarg happens during the schema fetch:

https://github.com/basho/riak_search/blob/master/src/riak_search_config.erl#L69

because the schema_table ETS table is not created when Search is not enabled.

One fix might be to catch this ets:lookup call, but it's probably a better idea to check whether Search is enabled at the start of the hook, and fail there (with a more descriptive reason) instead.

PB Service Broken

  1. I install the precommit hook on my test bucket (bin/search-cmd install test)
  2. I create a JSON object that looks like this {"name": "Andrew Z"} and store it in Riak (using my API and the key "1000")
  3. I create a RpbSearchQueryReq message, set ONLY the index to 'test' and the query (q) to "name:Andrew*"
  4. Send the message w/ the message type 27 to PBC port and receive back RpbErrorResp with the error code 0 and the message:

0: Error processing incoming message: error:badarg:[{erlang,list_to_float,
[["0.00000",101,43,48]]},
{riak_search_utils,to_float,
1},
{riak_search_pb_query,
encode_results,3},
{riak_search_pb_query,
process,2},
{riak_api_pb_server,
process_message,4},
{riak_api_pb_server,
handle_info,2},
{gen_server,handle_msg,5},
{proc_lib,init_p_do_apply,3}]

From the command line I get:
$ bin/search-cmd search-doc test 'name:Andrew*'

:: Searching for 'name:Andrew*' / '' in test...


index/id: test/1000
<<"name">> => <<"Andrew Z">>


:: Found 1 results.
:: Maximum score ["0.00000",101,43,48]

I noticed that the max score look exactly like the value in the error message.

error.log shows the following for that PBC request:

2012-06-29 14:03:26.916 [error] <0.17489.5> gen_server <0.17489.5> terminated with reason: {error,badarg,[{erlang,list_to_float,[["0.00000",101,43,48]]},{riak_search_utils,to_float,1},{riak_search_pb_query,encode_results,3},{riak_search_pb_query,process,2},{riak_api_pb_server,process_message,4},{riak_api_pb_server,handle_info,2},{gen_server,handle_msg,5},{proc_lib,init_p_do_apply,3}]}

2012-06-29 14:03:26.920 [error] <0.17489.5> CRASH REPORT Process <0.17489.5> with 0 neighbours exited with reason: {error,badarg,[{erlang,list_to_float,[["0.00000",101,43,48]]},{riak_search_utils,to_float,1},{riak_search_pb_query,encode_results,3},{riak_search_pb_query,process,2},{riak_api_pb_server,process_message,4},{riak_api_pb_server,handle_info,2},{gen_server,handle_msg,5},{proc_lib,init_p_do_apply,3}]} in gen_server:terminate/6

2012-06-29 14:03:26.923 [error] <0.62.0> Supervisor riak_api_pb_sup had child undefined started with {riak_api_pb_server,start_link,undefined} at <0.17489.5> exit with reason {error,badarg,[{erlang,list_to_float,[["0.00000",101,43,48]]},{riak_search_utils,to_float,1},{riak_search_pb_query,encode_results,3},{riak_search_pb_query,process,2},{riak_api_pb_server,process_message,4},{riak_api_pb_server,handle_info,2},{gen_server,handle_msg,5},{proc_lib,init_p_do_apply,3}]} in context child_terminated

riak_solr_sup unused

riak_solr_sup was previously merged from the riak_solr application but supervises nothing and is not linked to any other supervisor in the hierarchy. It can be removed.

Solr search with rows > 15 returns empty result

I am searching text inside of a description field of a post object. I have 50 objects each with the word "This" as part of the text.

When I query for the word "This" it should return the whole list of 50 post objects. But if I try to get a list of over 15 results, I get an empty response.

If I query with rows <= 15, then my search comes back fine:

curl "http://10.0.1.49:8100/solr/posts/select?start=0&rows=15&q=description:This"

<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
<int name="status">0</int>
<int name="QTime">7</int>
<lst name="params">
  <str name="indent">on</str>
  <str name="start">0</str>
  <str name="q">description:This</str>
  <str name="q.op">or</str>
  <str name="filter"></str>
  <str name="df">value</str>
  <str name="wt">standard</str>
  <str name="version">1.1</str>
  <str name="rows">50</str>
</lst>
</lst>
<result name="response" numFound="50" start="0" maxScore="0.353553">
<doc>
  <str name="id">1
  </str>
  <str name="category">Strategy
  </str>
  <str name="description">This is a pin 0
  </str>
  <str name="posterId">[email protected]
  </str>
</doc>
<doc>
  <str name="id">10
  </str>
  <str name="category">Casino
  </str>
  <str name="description">This is a pin 9
  </str>
  <str name="posterId">[email protected]
  </str>
</doc>
...More Results...

If I query with rows > 15, I get an empty result:

curl "http://10.0.1.49:8100/solr/posts/select?start=0&rows=16&q=description:This"
curl: (52) Empty reply from server

Also, If I query with rows > 15 when there is only 1 result, the query works fine and returns the one result.

After looking around it doesn't seem like any Riak search settings should limit the results to under 15 by default, so this seems like a bug.

solr update error on empty fields

The Solr update endpoint will fail if an empty field is passed.

<?xml version="1.0" encoding="UTF-8"?>
<add>
  <doc>
    <id>docA</id>
    <field name="terms">empty|en string|en test|en</field>
    <field name="lsh"></field>
    <field name="segments">d do doc docs</field>
  </doc>
</add>

Try to index that via

curl -v -XPOST -H "Content-Type: text/xml" --data-binary @docA.xml 'http://localhost:10018/solr/test-search/update'

The document will fail to index and the following will be logged.

2013-04-22 17:02:56.394 [error] <0.4452.0>@riak_solr_indexer_wm:malformed_request:37 Unable to parse request: {expected_binaries,<<"lsh">>,[]}

The single character wildcard search matches multiple characters

Description

The "?" wildcard should only match a single character. It currently matches many characters.

To reproduce

  • Install the Search hook
search-cmd install wildcards
  • Write an object
curl -XPUT http://localhost:8098/riak/wildcards/1 -H 'content-type:text/plain' -d 'The quick brown fox jumped over the lazy dog'
  • Search using a "?"
search-cmd search wildcards "qui?"

Expected

No results.

Actual

The written object matches the query.

search repair partition cmd

Summary

Add a command to Search that will allow a user to repair an index
partition. This is very useful in the case where a partition becomes
corrupt or lost (or an entire node's data is lost). Rather than
requiring a user to reindex all data Search can use adjacent
partitions to rebuild the missing/inconsistent one. This is also
generally useful to KV as well since it avoids the user performing a
list keys or all data and invoking read-repair. Essentially, it is a
targeted repair that enables Riak to converge replicas without
involving the entire cluster.

High-Level Thoughts

  • Each repair involves 3 partitions/vnodes; the target partition P
    under repair and it's adjacent source partitions P-1 and P+1
    which contain the replicas needed to repair the target.
  • Exploit the handoff mechanism to drive repairs. A repair is much
    like a fallback data handoff except it only involves primary
    partitions and needs to filter out replicas that don't belong on the
    target.
  • Repair should be async and not block incoming reads/writes on
    any of the vnodes.
  • User should be able to invoke search repair via search-cmd repair start P where P is the target.
  • User should be able to stop/cancel a repair via search-cmd repair stop P.
  • Each repair request should be persisted and only removed if the user
    stops it or if it is completed successfully. This is done so that
    in failure scenarios the user doesn't have to manually restart
    repair.
  • Potentially augment riak-admin transfers or add another cmd that
    shows more detail about the types of handoff and what their status
    is. E.g. the search repair handoff could describe how many indexes
    it has repaired or the amount of index data (in bytes) it has
    replicated vs. the total to be replicated. It could also report how
    long a particular handoff has been running and maybe it's 1 5 15
    minute replication rate.

Failure Scenarios

  • If a source partition dies then repair should restart on another
    primary source (or pick-up where it left off if the backend supports
    it). If no other sources are available then put the request back in
    the queue to be restarted later.
  • If the target partition dies then put the repair back in the queue
    to be restarted later. The reason to restart is because while the
    partition is down it is missing all incoming writes and the
    iteration over the source partitions won't include them.
  • What is TCP connection dies?
  • What if the data is corrupted in transport?

Assumptions

Precommit hook sometimes crashes when there are many siblings under a key

Hi,

I'm using Riak 1.3.1. The bucket in question has the following options enabled:

{"props":{"allow_mult": true, "search":true}}

Sometimes I have about 200 siblings under a single key. If I try to write another sibling, try to merge siblings or try to delete the key I get a "500 Internal Server Error". For example:

curl -XDELETE http://riak:8098/buckets/scanner/keys/3d7dc8ed1f828c727089033b2978a74ea7178833

The server response (personal details have been edited):

<html><head><title>500 Internal Server Error</title></head><body><h1>Internal Server Error</h1>The server encountered an error while processing this request:<br><pre>{error,badarg,
    [{erlang,iolist_to_binary,
         [{hook_crashed,
              {riak_search_kv_hook,precommit,error,
                  {badmatch,
                      [{{dict,3,16,16,8,80,48,
                            {[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},
                            {{[],[],[],[],[],[],[],[],[],[],
                              [[<<"X-Riak-VTag">>,49,121,108,121,69,87,87,48,
                                122,67,86,120,82,50,118,55,118,90,84,80,120,
                                106]],
                              [[<<"index">>]],
                              [],
                              [[<<"X-Riak-Last-Modified">>|
                                {1366,994414,313405}]],
                              [],[]}}},
                        {riak_idx_doc,<<"scanner">>,
                            <<"3d7dc8ed1f828c727089033b2978a74ea7178833">>,
                            [{<<"envelope_from_add">>,
                              <<"[email protected]">>,
                              [{<<"name1">>,[0,2]},
                               {<<"name3">>,[3]},
                               {<<"name2">>,[1]},
                               {<<"com">>,[4]}]},
                             {<<"envelope_to_add">>,<<"[email protected]">>,
                              [{<<"name4">>,[0]},
                               {<<"name5">>,[1]},
                               {<<"com">>,[3]},
                               {<<"name6">>,[2]}]},
                             {<<"envelope_to_domain_add">>,<<"name6.com">>,
                              [{<<"com">>,[1]},{<<"name6">>,[0]}]},
                             {<<"files">>,
                              <<"file136699328784114516-unpacked:25999">>,
                              [{<<"file136699328784114516-unpacked:25999">>,
                                [0]}]},
                             {<<"host_add">>,<<"1.2.3.4">>,
                              [{<<"1">>,[0]},
                               {<<"3">>,[2]},
                               {<<"2">>,[1]},
                               {<<"4">>,[3]}]},
                             {<<"message_id_add">>,
                              <<"<[email protected]>">>,
                              [{<<"name1">>,[2]},
                               {<<"name7">>,[0]},
                               {<<"name3">>,[3]},
                               {<<"name2">>,[1]},
                               {<<"com">>,[4]}]},
                             {<<"qs_time_int">>,<<"479">>,
                              [{<<"0000000479">>,[0]}]},
                             {<<"relay_int">>,<<"0">>,
                              [{<<"0000000000">>,[0]}]},
                             {<<"result">>,<<"SPAM-REJECTED">>,
                              [{<<"SPAM-REJECTED">>,[0]}]},
                             {<<"scanner">>,<<"SA">>,[{<<"SA">>,[0]}]},
                             {<<"score">>,<<"16.6/5.0">>,
                              [{<<"16.6/5.0">>,[0]}]},
                             {<<"size_int">>,<<"25999">>,
                              [{<<"0000025999">>,[0]}]},
                             {<<"subject_txt">>,
                              <<"Don't miss our exclusive offers!">>,
                              [{<<"don">>,[0]},
                               {<<"offers">>,[4]},
                               {<<"our">>,[2]},
                               {<<"exclusive">>,[3]},
                               {<<"miss">>,[1]}]},
                             {<<"timestamp_int">>,<<"1366993287">>,
                              [{<<"1366993287">>,[0]}]}],
                            [],[],true}},
                       {{dict,3,16,16,8,80,48,
                            {[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},
                            {{[],[],[],[],[],[],[],[],[],[],
                              [[<<"X-Riak-VTag">>,51,118,116,100,85,76,88,52,
                                81,70,118,122,78,66,111,112,55,55,114,102,101,
                                102]],
                              [[<<"index">>]],
                              [],
                              [[<<"X-Riak-Last-Modified">>|
                                {1366,994414,312370}]],
                              [],[]}}},
                        {riak_idx_doc,<<"scanner">>,
                            <<"3d7dc8ed1f828c727089033b2978a74ea7178833">>,
                            [{<<"envelope_from_add">>,
                              <<"[email protected]">>,
                              [{<<"name1">>,[0,2]},
                               {<<"name3">>,[3]},
                               {<<"name2">>,[1]},
                               {<<"com">>,[4]}]},
                             {<<"envelope_to_add">>,<<"[email protected]">>,
                              [{<<"name4">>,[0]},
                               {<<"name5">>,[1]},
                               {<<"com">>,[3]},
                               {<<"name6">>,[2]}]},
                             {<<"envelope_to_domain_add">>,<<"name6.com">>,
                              [{<<"com">>,[1]},{<<"name6">>,[0]}]},
                             {<<"files">>,
                              <<"file136699390984128832-unpacked:25998">>,
                              [{<<"file136699390984128832-unpacked:25998">>,
                                [0]}]},
                             {<<"host_add">>,<<"1.2.3.4">>,
                              [{<<"1">>,[0]},
                               {<<"3">>,[2]},
                               {<<"4">>,[3]},
                               {<<"2">>,[1]}]},
                             {<<"message_id_add">>,
                              <<"<[email protected]>">>,
                              [{<<"name1">>,[2]},
                               {<<"name7">>,[0]},
                               {<<"name3">>,[3]},
                               {<<"name2">>,[1]},
                               {<<"com">>,[4]}]},
                             {<<"qs_time_int">>,<<"303">>,
                              [{<<"0000000303">>,[0]}]},
                             {<<"relay_int">>,<<"0">>,
                              [{<<"0000000000">>,[0]}]},
                             {<<"result">>,<<"SPAM-REJECTED">>,
                              [{<<"SPAM-REJECTED">>,[0]}]},
                             {<<"scanner">>,<<"SA">>,[{<<"SA">>,[0]}]},
                             {<<"score">>,<<"16.6/5.0">>,
                              [{<<"16.6/5.0">>,[0]}]},
                             {<<"size_int">>,<<"25998">>,
                              [{<<"0000025998">>,[0]}]},
                             {<<"subject_txt">>,
                              <<"Don't miss our exclusive offers!">>,
                              [{<<"don">>,[0]},
                               {<<"offers">>,[4]},
                               {<<"our">>,[2]},
                               {<<"exclusive">>,[3]},
                               {<<"miss">>,[1]}]},
                             {<<"timestamp_int">>,<<"1366993909">>,
                              [{<<"1366993909">>,[0]}]}],
                            [],[],true}}]}}}],
         []},
     {wrq,append_to_response_body,2,[{file,"src/wrq.erl"},{line,205}]},
     {riak_kv_wm_object,handle_common_error,3,
         [{file,"src/riak_kv_wm_object.erl"},{line,998}]},
     {webmachine_resource,resource_call,3,
         [{file,"src/webmachine_resource.erl"},{line,183}]},
     {webmachine_resource,do,3,
         [{file,"src/webmachine_resource.erl"},{line,141}]},
     {webmachine_decision_core,resource_call,1,
         [{file,"src/webmachine_decision_core.erl"},{line,48}]},
     {webmachine_decision_core,decision,1,
         [{file,"src/webmachine_decision_core.erl"},{line,439}]},
     {webmachine_decision_core,handle_request,2,
         [{file,"src/webmachine_decision_core.erl"},{line,33}]}]}</pre><P><HR><ADDRESS>mochiweb+webmachine web server</ADDRESS></body></html>

The setup is a fairly standard one, except that there is a custom text analyzer for fields ending with "_add".

If you want me to provide more details, let me please know what logs or files should I inspect. The logs I checked don't provide more details than this.

This error happens only sometimes, but when it does, it's impossible to delete the object. The only workaround I know is to turn off the search. It's possible to delete the object then, but the corrupted data stay in the index.

Why not to split away lucene_parser?

This looks like a perfect candidate for unbundling (and adding as a dependency into rebar.config). Unbundling it allows few lines of code to be removed and will make the entire project more standartized.

So why not to move it into basho/lucene_parser?

riak_search code.

while I trying to create first users in Riak, I am facing following as below:

URL passing:

curl -H 'Content-Type: application/json' -X POST http://localhost:8080/riak-cs/user --data '{"email":"[email protected]", "name":"admin user"}'

Response:

<TITLE>404 Not Found</TITLE>

Not Found

The requested document was not found on this server.


mochiweb+webmachine web serverroot@localhost:/etc/riak#

Kindly help me on this.

500 Internal error on utf8 document search & utf8 key doubly encoded.

I have a 5 node cluster setup (based of the rebar dev). I got the source from:

http://downloads.basho.com.s3-website-us-east-1.amazonaws.com/riak/CURRENT/riak-1.2.1.tar.gz

I enabled riak_search in all the configurations.

And then made a bucket 'test01' and enabled postcommit indexing.

Then I created this document:

{
    "介绍" : "15岁的女孩与癌",
    "r_int"  : 15,
    "other" : "15岁的女孩与癌",
    "介绍介绍" : { "介绍": "12介绍" }
}

I performed this search:

http://localhost:8091/solr/test01/select?q=r_int:15

and I get this message:

{error,{error,{case_clause,{{badfun,#Fun},
                            [{mi_server,iterate,6},{mi_server,lookup,8}]}},
              [{riak_search_client,search_doc,8},
               {riak_solr_searcher_wm,run_query,1},
               {riak_solr_searcher_wm,to_xml,2},
               {webmachine_resource,resource_call,3},
               {webmachine_resource,do,3},
               {webmachine_decision_core,resource_call,1},
               {webmachine_decision_core,decision,1},
               {webmachine_decision_core,handle_request,2}]}}

Also searching with this doesn't work:

http://localhost:8091/solr/test01/select?q=介绍:15岁的女孩与癌

but when I doubly encode the key (介绍) in utf8 it works.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.