Giter Club home page Giter Club logo

elasticsearch-mapper-attachments's Introduction

IMPORTANT: this project now Read-Only and moved to elasticsearch repository (from elasticsearch 2.2.0):

If you have a question about the plugin, please use discuss.elastic.co. If you want to report a bug, please use elasticsearch repository.


Mapper Attachments Type for Elasticsearch

The mapper attachments plugin lets Elasticsearch index file attachments in over a thousand formats (such as PPT, XLS, PDF) using the Apache text extraction library Tika.

In practice, the plugin adds the attachment type when mapping properties so that documents can be populated with file attachment contents (encoded as base64).

Installation

In order to install the plugin, run:

bin/plugin install elasticsearch/elasticsearch-mapper-attachments/3.1.2

You need to install a version matching your Elasticsearch version:

Elasticsearch Attachments Plugin Docs
> 2.1 < 6.0 elasticsearch repository github
es-2.1 Build from source es-2.1
2.1.2 3.1.2 3.1.2
2.1.1 3.1.1 3.1.1
2.1.0 3.1.0 3.1.0
es-2.0 Build from source es-2.0
2.0.2 3.0.4 3.0.4
2.0.1 3.0.3 3.0.3
2.0.0 3.0.2 3.0.2
2.0.0-beta2 3.0.1 3.0.1
2.0.0-beta1 3.0.0 3.0.0
es-1.7 2.7.1 2.7.1
es-1.6 2.6.0 2.6.0
es-1.5 2.5.0 2.5.0
es-1.4 2.4.3 2.4.3
es-1.3 2.3.2 2.3.2
es-1.2 2.2.1 2.2.1
es-1.1 2.0.0 2.0.0
es-1.0 2.0.0 2.0.0
es-0.90 1.9.0 1.9.0

To build a SNAPSHOT version, you need to build it with Maven:

gradle clean assemble
plugin --install mapper-attachments \
       --url file:target/releases/elasticsearch-mapper-attachments-X.X.X-SNAPSHOT.zip

Hello, world

Create a property mapping using the new type attachment:

POST /trying-out-mapper-attachments
{
  "mappings": {
    "person": {
      "properties": {
        "cv": { "type": "attachment" }
}}}}

Index a new document populated with a base64-encoded attachment:

POST /trying-out-mapper-attachments/person/1
{
  "cv": "e1xydGYxXGFuc2kNCkxvcmVtIGlwc3VtIGRvbG9yIHNpdCBhbWV0DQpccGFyIH0="
}

Search for the document using words in the attachment:

POST /trying-out-mapper-attachments/person/_search
{
  "query": {
    "query_string": {
      "query": "ipsum"
}}}

If you get a hit for your indexed document, the plugin should be installed and working.

Usage

Using the attachment type is simple, in your mapping JSON, simply set a certain JSON element as attachment, for example:

PUT /test
PUT /test/person/_mapping
{
    "person" : {
        "properties" : {
            "my_attachment" : { "type" : "attachment" }
        }
    }
}

In this case, the JSON to index can be:

PUT /test/person/1
{
    "my_attachment" : "... base64 encoded attachment ..."
}

Or it is possible to use more elaborated JSON if content type, resource name or language need to be set explicitly:

PUT /test/person/1
{
    "my_attachment" : {
        "_content_type" : "application/pdf",
        "_name" : "resource/name/of/my.pdf",
        "_language" : "en",
        "_content" : "... base64 encoded attachment ..."
    }
}

The attachment type not only indexes the content of the doc in content sub field, but also automatically adds meta data on the attachment as well (when available).

The metadata supported are:

  • date
  • title
  • name only available if you set _name see above
  • author
  • keywords
  • content_type
  • content_length is the original content_length before text extraction (aka file size)
  • language

They can be queried using the "dot notation", for example: my_attachment.author.

Both the meta data and the actual content are simple core type mappers (string, date, ...), thus, they can be controlled in the mappings. For example:

PUT /test/person/_mapping
{
    "person" : {
        "properties" : {
            "file" : {
                "type" : "attachment",
                "fields" : {
                    "content" : {"index" : "no"},
                    "title" : {"store" : "yes"},
                    "date" : {"store" : "yes"},
                    "author" : {"analyzer" : "myAnalyzer"},
                    "keywords" : {"store" : "yes"},
                    "content_type" : {"store" : "yes"},
                    "content_length" : {"store" : "yes"},
                    "language" : {"store" : "yes"}
                }
            }
        }
    }
}

In the above example, the actual content indexed is mapped under fields name content, and we decide not to index it, so it will only be available in the _all field. The other fields map to their respective metadata names, but there is no need to specify the type (like string or date) since it is already known.

Copy To feature

If you want to use copy_to feature, you need to define it on each sub-field you want to copy to another field:

PUT /test/person/_mapping
{
  "person": {
    "properties": {
      "file": {
        "type": "attachment",
        "fields": {
          "content": {
            "type": "string",
            "copy_to": "copy"
          }
        }
      },
      "copy": {
        "type": "string"
      }
    }
  }
}

In this example, the extracted content will be copy as well to copy field.

Querying or accessing metadata

If you need to query on metadata fields, use the attachment field name dot the metadata field. For example:

DELETE /test
PUT /test
PUT /test/person/_mapping
{
  "person": {
    "properties": {
      "file": {
        "type": "attachment",
        "fields": {
          "content_type": {
            "type": "string",
            "store": true
          }
        }
      }
    }
  }
}
PUT /test/person/1?refresh=true
{
  "file": "IkdvZCBTYXZlIHRoZSBRdWVlbiIgKGFsdGVybmF0aXZlbHkgIkdvZCBTYXZlIHRoZSBLaW5nIg=="
}
GET /test/person/_search
{
  "fields": [ "file.content_type" ],
  "query": {
    "match": {
      "file.content_type": "text plain"
    }
  }
}

Will give you:

{
   "took": 2,
   "timed_out": false,
   "_shards": {
      "total": 5,
      "successful": 5,
      "failed": 0
   },
   "hits": {
      "total": 1,
      "max_score": 0.16273327,
      "hits": [
         {
            "_index": "test",
            "_type": "person",
            "_id": "1",
            "_score": 0.16273327,
            "fields": {
               "file.content_type": [
                  "text/plain; charset=ISO-8859-1"
               ]
            }
         }
      ]
   }
}

Indexed Characters

By default, 100000 characters are extracted when indexing the content. This default value can be changed by setting the index.mapping.attachment.indexed_chars setting. It can also be provided on a per document indexed using the _indexed_chars parameter. -1 can be set to extract all text, but note that all the text needs to be allowed to be represented in memory:

PUT /test/person/1
{
    "my_attachment" : {
        "_indexed_chars" : -1,
        "_content" : "... base64 encoded attachment ..."
    }
}

Metadata parsing error handling

While extracting metadata content, errors could happen for example when parsing dates. Parsing errors are ignored so your document is indexed.

You can disable this feature by setting the index.mapping.attachment.ignore_errors setting to false.

Language Detection

By default, language detection is disabled (false) as it could come with a cost. This default value can be changed by setting the index.mapping.attachment.detect_language setting. It can also be provided on a per document indexed using the _detect_language parameter.

Note that you can force language using _language field when sending your actual document:

{
    "my_attachment" : {
        "_language" : "en",
        "_content" : "... base64 encoded attachment ..."
    }
}

Highlighting attachments

If you want to highlight your attachment content, you will need to set "store": true and "term_vector":"with_positions_offsets" for your attachment field. Here is a full script which does it:

DELETE /test
PUT /test
PUT /test/person/_mapping
{
  "person": {
    "properties": {
      "file": {
        "type": "attachment",
        "fields": {
          "content": {
            "type": "string",
            "term_vector":"with_positions_offsets",
            "store": true
          }
        }
      }
    }
  }
}
PUT /test/person/1?refresh=true
{
  "file": "IkdvZCBTYXZlIHRoZSBRdWVlbiIgKGFsdGVybmF0aXZlbHkgIkdvZCBTYXZlIHRoZSBLaW5nIg=="
}
GET /test/person/_search
{
  "fields": [],
  "query": {
    "match": {
      "file.content": "king queen"
    }
  },
  "highlight": {
    "fields": {
      "file.content": {
      }
    }
  }
}

It gives back:

{
   "took": 9,
   "timed_out": false,
   "_shards": {
      "total": 1,
      "successful": 1,
      "failed": 0
   },
   "hits": {
      "total": 1,
      "max_score": 0.13561106,
      "hits": [
         {
            "_index": "test",
            "_type": "person",
            "_id": "1",
            "_score": 0.13561106,
            "highlight": {
               "file.content": [
                  "\"God Save the <em>Queen</em>\" (alternatively \"God Save the <em>King</em>\"\n"
               ]
            }
         }
      ]
   }
}

Stand alone runner

If you want to run some tests within your IDE, you can use StandaloneRunner class. It accepts arguments:

  • -u file://URL/TO/YOUR/DOC
  • --size set extracted size (default to mapper attachment size)
  • BASE64 encoded binary

Example:

StandaloneRunner BASE64Text
StandaloneRunner -u /tmp/mydoc.pdf
StandaloneRunner -u /tmp/mydoc.pdf --size 1000000

It produces something like:

## Extracted text
--------------------- BEGIN -----------------------
This is the extracted text
---------------------- END ------------------------
## Metadata
- author: null
- content_length: null
- content_type: application/pdf
- date: null
- keywords: null
- language: null
- name: null
- title: null

License

This software is licensed under the Apache 2 license, quoted below.

Copyright 2009-2014 Elasticsearch <http://www.elasticsearch.org>

Licensed under the Apache License, Version 2.0 (the "License"); you may not
use this file except in compliance with the License. You may obtain a copy of
the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations under
the License.

elasticsearch-mapper-attachments's People

Contributors

alh3im avatar bradtimmerman avatar clintongormley avatar colings86 avatar dadoonet avatar fcamblor avatar henac avatar jasontedor avatar johtani avatar jpountz avatar kimchy avatar martijnvg avatar mikemccand avatar paikan avatar richardwilly98 avatar rjernst avatar rmuir avatar s1monw avatar tlrx 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  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

elasticsearch-mapper-attachments's Issues

Indexing of message/rfc822 attachment never returns

I am using elasticsearch 1.0.0 and elasticsearch-mapper-attachments 2.0.0.RC1
I am trying to index attachment with Content-Type: "message/rfc822".
The index operation never returns.

Steps to Reproduce:

curl -XPUT 'http://192.168.2.158:9200/test_one/' -d '{
    "settings" : {
        "number_of_shards" : "1",
        "index": {
            "analysis" : {
                "analyzer" : {
                    "soundex_analyzer" : {
                        "tokenizer" : "standard",
                        "filter" : ["standard", "lowercase", "soundex_filter"]
                    }
                },
                "filter" : {
                    "soundex_filter" : {
                        "type" : "phonetic",
                        "encoder" : "soundex",
                        "replace" : "true"
                    }
                }
            },
            "mapping" : {
                "attachment" : {
                    "ignore_errors" : "false"
                }
            }
        }
    },
    "mappings" : {
        "emailattachment":{
            "_source" : { "enabled" : "false" },
            "_all": {     "enabled" : "false" },
            "properties" : {
               "from" : { "type" : "string",  
            "index" : "analyzed",       
            "store" : "yes",    
            "term_vector" : "no",               "norms.enabled" : "false",  
            "index_options" : "docs"},
               "attachment" : {    "type" : "attachment", 
                "_indexed_chars":"500000000", 
                "store" : "no" },
               "attachmentsoundex":{"type" : "attachment", 
                "_indexed_chars":"500000000", 
                "store" : "no",
                                "fields" : {
                                           "attachmentsoundex" : { "analyzer" : "soundex_analyzer" }
                                }
                         }
            }
        }
    }
}'

curl -X POST "http://192.168.2.158:9200/test_one/emailattachment" -d @test2.json

Content of test2.json:
Sorry, I am getting a 'message is too long' error.
Can I send it in any other way?

Krzysztof

Nothing happens at all; the file is indexed without the metadata

delete the index

curl -XDELETE localhost:9200/attaches/person/1

prepare format

curl -XPUT localhost:9200/attaches/person/1 -d '{
"person" : {
"properties" : {
"my_attachment" : { "type" : "attachment" }
}
}
}

insert document

curl -XPUT localhost:9200/attaches/person/1 -d '{
"my_attachment": "0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAKgAAAAAAAAAA\nEAAALAAAAAEAAAD+////AAAAACkAAAD/////////////////////////////////////////////\n////////////////////////////////////////////////////////////////////////////\n////////////////////////////////////////////////////////////////////////////\n////////////////////////////////////////////////////////////////////////////\n////////////////////////////////////////////////////////////////////////////\n////////////////////////////////////////////////////////////////////////////\n////////////////////////////////////////////////////////////////////////////\n///////////////////////////////////////////////////////////////////////////s\npcEAA4AJBAAA8BK/AAAAAAAAEAAAAAAACAAAYAoAAA4AYmpiaoDOgM4AAAAAAAAAAAAAAAAAAAAA\nAAAJBBYANBAAAOKkAADipAAAYAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA\nAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAALcAAAAAAI4GAAAAAAAAjgYAANET\nAAAAAAAA0RMAAAAAAADREwAAAAAAANETAAAAAAAA0RMAABQAAAAAAAAAAAAAAP////8AAAAA5RMA\nAAAAAADlEwAAAAAAAOUTAAAAAAAA5RMAAAwAAADxEwAADAAAAOUTAAAAAAAA1hgAAOQBAAD9EwAA\nAAAAAP0TAAAAAAAA/RMAAAAAAAD9EwAAAAAAAP0TAAAAAAAA2BQAAAAAAADYFAAAAAAAANgUAAAA\nAAAAeRgAAAIAAAB7GAAAAAAAAHsYAAAAAAAAexgAAAAAAAB7GAAAAAAAAHsYAAAAAAAAexgAAAAA\nAAC6GgAAogIAAFwdAADuAAAAexgAABUAAAAAAAAAAAAAAAAAAAAAAAAA0RMAAAAAAADYFAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAADYFAAAAAAAANgUAAAAAAAA2BQAAAAAAADYFAAAAAAAAHsYAAAAAAAA\nAAAAAAAAAADREwAAAAAAANETAAAAAAAA/RMAAAAAAAAAAAAAAAAAAP0TAADbAAAAkBgAABYAAABW\nFQAAAAAAAFYVAAAAAAAAVhUAAAAAAADYFAAACgAAANETAAAAAAAA/RMAAAAAAADREwAAAAAAAP0T\nAAAAAAAAeRgAAAAAAAAAAAAAAAAAAFYVAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAA2BQAAAAAAAB5GAAAAAAAAAAAAAAAAAAAVhUAAAAAAABWFQAA\nHgAAAO0XAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAORgAAAAAAAD9EwAAAAAAAP////8AAAAAAAzXqwE0\nywEAAAAAAAAAAOUTAAAAAAAA4hQAAAoAAAAFGAAACAAAAAAAAAAAAAAAZRgAABQAAACmGAAAMAAA\nANYYAAAAAAAADRgAACwAAABKHgAAAAAAAOwUAABqAAAASh4AABAAAAA5GAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAEoeAAAAAAAAAAAAAAAAAADREwAAAAAAADkYAAAsAAAA2BQAAAAAAADYFAAAAAAAAFYV\nAAAAAAAA2BQAAAAAAADYFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2BQA\nAAAAAADYFAAAAAAAANgUAAAAAAAAexgAAAAAAAB7GAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAVhUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANgUAAAA\nAAAA2BQAAAAAAADYFAAAAAAAANYYAAAAAAAA2BQAAAAAAADYFAAAAAAAANgUAAAAAAAA2BQAAAAA\nAAAAAAAAAAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAA\nAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA\n/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAEoeAAAAAAAA2BQAAAAAAADY\nFAAAAAAAANgUAAAAAAAA2BQAAAAAAADYFAAAAAAAANgUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYFAAAAAAAANgUAAAAAAAA2BQA\nAAAAAACOBgAACQwAAJcSAAA6AQAABQASAQAACQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEdvb2ds\nZSBNYXBzIEtleWJvYXJkIFNob3J0Y3V0IExpc3QNR29vZ2xlIE1hcHMgY2FuIGFsc28gYmUgbmF2\naWdhdGVkIGJ5IHVzaW5nIGtleWJvYXJkIHNob3J0Y3V0cyB0byBtb3ZlIHRoZSBtYXAgYW5kIHpv\nb20gaW4gYW5kIG91dC4NVG8gbW92ZSBub3J0aCwgdXNlIHRoZSB1cCBhcnJvdyBrZXkgdG8gbW92\nZSBhIHNtYWxsIGFtb3VudCBvciB0aGUgcGFnZSB1cCBrZXkgdG8gbW92ZSBhIGxhcmdlciBhbW91\nbnQuDVRvIG1vdmUgc291dGgsIHVzZSB0aGUgZG93biBhcnJvdyBrZXkgdG8gbW92ZSBhIHNtYWxs\nIGFtb3VudCBvciB0aGUgcGFnZSBkb3duIGtleSB0byBtb3ZlIGEgbGFyZ2VyIGFtb3VudC4NVG8g\nbW92ZSB3ZXN0LCB1c2UgdGhlIGxlZnQgYXJyb3cga2V5IHRvIG1vdmUgYSBzbWFsbCBhbW91bnQg\nb3IgdGhlIGhvbWUga2V5IHRvIG1vdmUgYSBsYXJnZXIgYW1vdW50Lg1UbyBtb3ZlIGVhc3QsIHVz\nZSB0aGUgcmlnaHQgYXJyb3cga2V5IHRvIG1vdmUgYSBzbWFsbCBhbW91bnQgb3IgdGhlIGVuZCBr\nZXkgdG8gbW92ZSBhIGxhcmdlciBhbW91bnQuDVRvIHpvb20gaW4sIHVzZSB0aGUgcGx1cyBrZXku\nIFRvIHpvb20gb3V0LCB1c2UgdGhlIG1pbnVzIGtleS4NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAIwgA\nAF8KAABgCgAA/PHmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBVo\n1ztoABZoxnlsAENKIABhSiAAABQVaNc7aAAWaNc7aABDSiAAYUogAAAGFmjDHOMAAwAIAAAjCAAA\nhggAAO0IAABYCQAAvQkAACIKAABgCgAA9wAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADqAAAAAAAA\nAAAAAAAA6gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAgPAAomAAtGAQBnZNc7aAAABAAAZ2TXO2gAAAcBAAMkAWEkAWdkwxzjAAAHMgAxkGgBOnDG\neWwAH7DQLyCw4D0hsKAFIrCgBSOQoAUkkKAFJbAAABew0AIYsNACDJDQAgAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqBBEAEgABAAsB\nDwAHAAMAAwADAAAABAAIAAAAmAAAAJ4AAACeAAAAngAAAJ4AAACeAAAAngAAAJ4AAACeAAAANgYA\nADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAAdgIAAHYCAAB2AgAAdgIAAHYCAAB2AgAA\ndgIAAHYCAAB2AgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAAPgIAADYGAAA2BgAANgYAADYGAAA2\nBgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG\nAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAAKgAAAA2BgAANgYAABYAAAA2BgAANgYA\nADYGAAA2BgAANgYAADYGAAA2BgAANgYAALgAAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA\nNgYAADYGAAA2BgAANgYAADYGAABoAQAASAEAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2\nBgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG\nAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA\nADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA\nNgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2\nBgAAsAMAADYGAAAyBgAAGAAAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAE\nAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAMgYAACgCAADYAQAA6AEA\nACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAA\nIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAg\nBAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAE\nAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQA\nADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAA\nMAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAADgBAABYAQAA+AEAAAgCAAAYAgAAVgIAAH4CAAAg\nAAAAT0oDAFBKAwBRSgMAX0gBBG1ICQRuSAkEc0gJBHRICQQAAAAASgAAYPH/AgBKAAwQAADGeWwA\nAAAGAE4AbwByAG0AYQBsAAAADAAAABJkFAEBABSkyAAYAENKFgBfSAEEYUoWAG1ICQRzSAkEdEgJ\nBF4AAUABAAIAXgAMFBAAwxzjAJAACQBIAGUAYQBkAGkAbgBnACAAMQAAABAAAQAGJAETpPAAFKQ8\nAEAmACIANQiBQ0ogAEtIIABPSgQAUEoAAFFKBABcCIFeSgAAYUogAAAAAAAAAAAAAAAAAAAAAABE\nAEEg8v+hAEQADA0AAAAAAAAQABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAA\nRgBvAG4AdAAAAAAAUgBpAPP/swBSAAwdAAAAAAAAMAYMAFQAYQBiAGwAZQAgAE4AbwByAG0AYQBs\nAAAAHAAX9gMAADTWBgABCgNsADTWBgABBQMAAGH2AwAAAgALAAAAKABrIPT/wQAoAAANAAAAAAAA\nMAYHAE4AbwAgAEwAaQBzAHQAAAACAAwAAAAAAEQAs0ABAPIARAAMFAAA1ztoACACDgBMAGkAcwB0\nACAAUABhAHIAYQBnAHIAYQBwAGgAAAANAA8AD4TQAl6E0AJtJAEAAABWAP4vogABAVYADAABAMMc\n4wCQAA4ASABlAGEAZABpAG4AZwAgADEAIABDAGgAYQByAAAAIgA1CAFDSiAAS0ggAE9KBABQSgAA\nUUoEAFwIAV5KAABhSiAAUEsDBBQABgAIAAAAIQCCirwT+gAAABwCAAATAAAAW0NvbnRlbnRfVHlw\nZXNdLnhtbKyRy2rDMBBF94X+g9C22HK6KKXYzqJJd30s0g8Y5LEtao+ENAnJ33fsuFC6CC10IxBi\nzpl7Va6P46AOGJPzVOlVXmiFZH3jqKv0++4pu9cqMVADgyes9AmTXtfXV+XuFDApmaZU6Z45PBiT\nbI8jpNwHJHlpfRyB5Ro7E8B+QIfmtijujPXESJzxxNB1+SoLRNegeoPILzCKx7Cg8Pv5DCSAmAtY\nq8czYVqi0hDC4CywRDAHan7oM9+2zmLj7X4UaT6DF9jNBDO/XGD1P+ov5wZb2A+stkfp4lx/xCH9\nLdtSay6Tc/7Uu5AuGC6Xt7Rh5r+tPwEAAP//AwBQSwMEFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsA\nAABfcmVscy8ucmVsc4SPz2rDMAyH74W9g9F9UdLDGCV2L6WQQy+jfQDhKH9oIhvbG+vbT8cGCrsI\nhKTv96k9/q6L+eGU5yAWmqoGw+JDP8to4XY9v3+CyYWkpyUIW3hwhqN727VfvFDRozzNMRulSLYw\nlRIPiNlPvFKuQmTRyRDSSkXbNGIkf6eRcV/XH5ieGeA2TNP1FlLXN2Cuj6jJ/7PDMMyeT8F/ryzl\nRQRuN5RMaeRioagv41O9kKhlqtQe0LW4+db9AQAA//8DAFBLAwQUAAYACAAAACEAa3mWFoMAAACK\nAAAAHAAAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWwMzE0KwyAQQOF9oXeQ2TdjuyhFYrLL\nrrv2AEOcGkHHoNKf29fl44M3zt8U1ZtLDVksnAcNimXNLoi38Hwspxuo2kgcxSxs4ccV5ul4GMm0\njRPfSchzUX0j1ZCFrbXdINa1K9Uh7yzdXrkkaj2LR1fo0/cp4kXrKyYKAjj9AQAA//8DAFBLAwQU\nAAYACAAAACEAlrWt4pYGAABQGwAAFgAAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/Y\ndyB0b2MndhoHdYrYsZstTRvEboceaYmW2FCiQNJJfRva44ABw7phhxXYbYdhW4EW2KX7NNk6bB3Q\nr7BHUpLFWF6SNtiKrT4kEvnj+/8eH6mr1+7HDB0SISlP2l79cs1DJPF5QJOw7d0e9i+teUgqnASY\n8YS0vSmR3rWN99+7itdVRGKCYH0i13Hbi5RK15eWpA/DWF7mKUlgbsxFjBW8inApEPgI6MZsablW\nW12KMU08lOAYyN4aj6lP0FCT9DZy4j0Gr4mSesBnYqBJE2eFwQYHdY2QU9llAh1i1vaAT8CPhuS+\n8hDDUsFE26uZn7e0cXUJr2eLmFqwtrSub37ZumxBcLBseIpwVDCt9xutK1sFfQNgah7X6/W6vXpB\nzwCw74OmVpYyzUZ/rd7JaZZA9nGedrfWrDVcfIn+ypzMrU6n02xlsliiBmQfG3P4tdpqY3PZwRuQ\nxTfn8I3OZre76uANyOJX5/D9K63Vhos3oIjR5GAOrR3a72fUC8iYs+1K+BrA12oZfIaCaCiiS7MY\n80QtirUY3+OiDwANZFjRBKlpSsbYhyju4ngkKNYM8DrBpRk75Mu5Ic0LSV/QVLW9D1MMGTGj9+r5\n96+eP0XHD54dP/jp+OHD4wc/WkLOqm2chOVVL7/97M/HH6M/nn7z8tEX1XhZxv/6wye//Px5NRDS\nZybOiy+f/PbsyYuvPv39u0cV8E2BR2X4kMZEopvkCO3zGBQzVnElJyNxvhXDCNPyis0klDjBmksF\n/Z6KHPTNKWaZdxw5OsS14B0B5aMKeH1yzxF4EImJohWcd6LYAe5yzjpcVFphR/MqmXk4ScJq5mJS\nxu1jfFjFu4sTx7+9SQp1Mw9LR/FuRBwx9xhOFA5JQhTSc/yAkArt7lLq2HWX+oJLPlboLkUdTCtN\nMqQjJ5pmi7ZpDH6ZVukM/nZss3sHdTir0nqLHLpIyArMKoQfEuaY8TqeKBxXkRzimJUNfgOrqErI\nwVT4ZVxPKvB0SBhHvYBIWbXmlgB9S07fwVCxKt2+y6axixSKHlTRvIE5LyO3+EE3wnFahR3QJCpj\nP5AHEKIY7XFVBd/lbobod/ADTha6+w4ljrtPrwa3aeiINAsQPTMR2pdQqp0KHNPk78oxo1CPbQxc\nXDmGAvji68cVkfW2FuJN2JOqMmH7RPldhDtZdLtcBPTtr7lbeJLsEQjz+Y3nXcl9V3K9/3zJXZTP\nZy20s9oKZVf3DbYpNi1yvLBDHlPGBmrKyA1pmmQJ+0TQh0G9zpwOSXFiSiN4zOq6gwsFNmuQ4Ooj\nqqJBhFNosOueJhLKjHQoUcolHOzMcCVtjYcmXdljYVMfGGw9kFjt8sAOr+jh/FxQkDG7TWgOnzmj\nFU3grMxWrmREQe3XYVbXQp2ZW92IZkqdw61QGXw4rxoMFtaEBgRB2wJWXoXzuWYNBxPMSKDtbvfe\n3C3GCxfpIhnhgGQ+0nrP+6hunJTHirkJgNip8JE+5J1itRK3lib7BtzO4qQyu8YCdrn33sRLeQTP\nvKTz9kQ6sqScnCxBR22v1VxuesjHadsbw5kWHuMUvC51z4dZCBdDvhI27E9NZpPlM2+2csXcJKjD\nNYW1+5zCTh1IhVRbWEY2NMxUFgIs0Zys/MtNMOtFKWAj/TWkWFmDYPjXpAA7uq4l4zHxVdnZpRFt\nO/ualVI+UUQMouAIjdhE7GNwvw5V0CegEq4mTEXQL3CPpq1tptzinCVd+fbK4Ow4ZmmEs3KrUzTP\nZAs3eVzIYN5K4oFulbIb5c6vikn5C1KlHMb/M1X0fgI3BSuB9oAP17gCI52vbY8LFXGoQmlE/b6A\nxsHUDogWuIuFaQgquEw2/wU51P9tzlkaJq3hwKf2aYgEhf1IRYKQPShLJvpOIVbP9i5LkmWETESV\nxJWpFXtEDgkb6hq4qvd2D0UQ6qaaZGXA4E7Gn/ueZdAo1E1OOd+cGlLsvTYH/unOxyYzKOXWYdPQ\n5PYvRKzYVe16szzfe8uK6IlZm9XIswKYlbaCVpb2rynCObdaW7HmNF5u5sKBF+c1hsGiIUrhvgfp\nP7D/UeEz+2VCb6hDvg+1FcGHBk0Mwgai+pJtPJAukHZwBI2THbTBpElZ02atk7ZavllfcKdb8D1h\nbC3ZWfx9TmMXzZnLzsnFizR2ZmHH1nZsoanBsydTFIbG+UHGOMZ80ip/deKje+DoLbjfnzAlTTDB\nNyWBofUcmDyA5LcczdKNvwAAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAB0aGVt\nZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeCdwhvb9O6EJEm3YjQ\nrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjsjkBSFk6J2TtksGCC\njm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9oPGbAXzFJL1iEHvV\nABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8DAFBLAQItABQABgAI\nAAAAIQCCirwT+gAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB\nAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAAKwEAAF9yZWxzLy5yZWxzUEsB\nAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFAIAAHRoZW1lL3RoZW1lL3Ro\nZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEAlrWt4pYGAABQGwAAFgAAAAAAAAAAAAAAAADR\nAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCftgAAABsBAAAnAAAA\nAAAAAAAAAAAAAJsJAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHNQSwUG\nAAAAAAUABQBdAQAAlgoAAAAAPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0\nYW5kYWxvbmU9InllcyI/Pg0KPGE6Y2xyTWFwIHhtbG5zOmE9Imh0dHA6Ly9zY2hlbWFzLm9wZW54\nbWxmb3JtYXRzLm9yZy9kcmF3aW5nbWwvMjAwNi9tYWluIiBiZzE9Imx0MSIgdHgxPSJkazEiIGJn\nMj0ibHQyIiB0eDI9ImRrMiIgYWNjZW50MT0iYWNjZW50MSIgYWNjZW50Mj0iYWNjZW50MiIgYWNj\nZW50Mz0iYWNjZW50MyIgYWNjZW50ND0iYWNjZW50NCIgYWNjZW50NT0iYWNjZW50NSIgYWNjZW50\nNj0iYWNjZW50NiIgaGxpbms9ImhsaW5rIiBmb2xIbGluaz0iZm9sSGxpbmsiLz4AAAAAYAIAAA4A\nABAAAAwA/////wAIAABgCgAABgAAAAAIAABgCgAABwAAAA8AAPA4AAAAAAAG8BgAAAACCAAAAgAA\nAAEAAAABAAAAAQAAAAIAAABAAB7xEAAAAP//AAAAAP8AgICAAPcAABAADwAC8JIAAAAQAAjwCAAA\nAAEAAAABBAAADwAD8DAAAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAA\nAAQAAAUAAAAPAATwQgAAABIACvAIAAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAI\nAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAAAAAAABiAgAABwAAAAAAYgIAAAcAAAAAABUAAAAdAAAA\nIwAAAIUAAACFAAAAhgAAAIYAAADtAAAA7QAAAFgBAABYAQAAvQEAAL0BAAAiAgAAIgIAAF8CAABi\nAgAABAAHAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAHAAEAoUXtCu5mSOL/D/8P/w//D/8P\n/w//D/8P/w8QAAEAAAAXEAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhNACEYSY/l6E0AJghJj+T0oB\nAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABkQAAAPhKAFEYSY\n/l6EoAVghJj+T0oFAFFKBQBeSgUAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEA\nAAAAAAAVEAAAD4RwCBGEmP5ehHAIYISY/k9KBgBRSgYAbygAh2gAAAAAiEgAAAEAp/ABAAAAF5AA\nAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4RACxGEmP5ehEALYISY/k9KAQBRSgEAbygAh2gAAAAAiEgA\nAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZEAAAD4QQDhGEmP5ehBAOYISY/k9KBQBRSgUA\nXkoFAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+E4BARhJj+\nXoTgEGCEmP5PSgYAUUoGAG8oAIdoAAAAAIhIAAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAA\nFRAAAA+EsBMRhJj+XoSwE2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAAAAAA\nAAAAAGgBAAAAAAAAGRAAAA+EgBYRhJj+XoSAFmCEmP5PSgUAUUoFAF5KBQBvKACHaAAAAACISAAA\nAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhFAZEYSY/l6EUBlghJj+T0oGAFFKBgBv\nKACHaAAAAACISAAAAQCn8AEAAAChRe0KAAAAAAAAAAAAAAAA////////AQAAAAAA//8BAAAAEgAB\nAAkEAwAJBAUACQQBAAkEAwAJBAUACQQBAAkEAwAJBAUACQQFAAAABAAAAAgAAADlAAAAAAAAAAQA\nAACEeioA1ztoAMZ5bAAuRYMAwxzjAAAAAABgAgAAYgIAAAAAAAABAAAA/0ACEAAAAAAAAABgAgAA\ncAAAEABAAAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8BAAgAAAAAAAAAAAAAAP//AQAAAAAA//8A\nAAIA//8AAAAA//8AAAIA//8AAAAACAAAAEcekAEAAAICBgMFBAUCAwSHKgAgAAAAgAgAAAAAAAAA\n/wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUekAECAAUFAQIBBwYCBQcA\nAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMukAEAAAILBgQCAgICAgSHKgAg\nAAAAgAgAAAAAAAAA/wEAAAAAAABBAHIAaQBhAGwAAAA3LpABAAACDwUCAgIEAwIE7wIAoHsgAEAA\nAAAAAAAAAJ8AAAAAAAAAQwBhAGwAaQBiAHIAaQAAADcekAEAAAIEBQMFBAYDAgTvAgCgSwAAQAAA\nAAAAAAAAnwAAAAAAAABDAGEAbQBiAHIAaQBhAAAAPz2QAQAAAgcDCQICBQIEBIcqACAAAACACAAA\nAAAAAAD/AQAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAADsOkAECAAUAAAAAAAAAAAAAAAAA\nAAAAEAAAAAAAAAAAAAAAgAAAAABXAGkAbgBnAGQAaQBuAGcAcwAAAEEekAEAAAAAAAAAAAAAAADv\nAgCg6yAAQgAAAAAAAAAAnwAAAAAAAABDAGEAbQBiAHIAaQBhACAATQBhAHQAaAAAACIABADxCIgY\nAPDQAgAAaAEAAAAAhCPoZpQj6GYAAAAAAwAQAAAAhQAAANsBAAABAAcAAAAEAAOQCwAAAIUAAADb\nAQAAAQAHAAAACwAAAAAAAADhAQDwEAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgBaAFtAC0\nAIGBcjAAAAAAAAAAAAAAAAAAAFkCAABZAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAQyg1EA8BAACAD8/QEAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAISFgAAAAACfD/DwEIJFAAAOQEAAD///9/////f////3////9/\n////f////3////9/1ztoAAAEAAAyAAAAAAAAAAAAAAAAAAAAAAAAAAAAIQQAAAAAAAAAAAAAAAAA\nAAAAAAAQHAAABwAAAAAAAAAAAHgAAAB4AAAAAAAAAAAAAACgBQAA//8SAAAAAAAAAB4ARwBvAG8A\nZwBsAGUAIABNAGEAcABzACAASwBlAHkAYgBvAGEAcgBkACAAUwBoAG8AcgB0AGMAdQB0AHMADgBX\nAG8AcgBrAGkAbgBnACAAYQB0ACAATgBJAEgAJABnAG8AbwBnAGwAZQAsACAAbQBhAHAALAAgAHMA\naABvAHIAdABjAHUAdAAsACAAawBlAHkAYgBvAGEAcgBkACwAIAA1ADAAOAAAAAcATgBJAEgALwBP\nAEgAUgALAGQAaQBjAGsAZQByAHMAbwBuAGcAbAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAGAAAA\nAQAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEA\nAADghZ/y+U9oEKuRCAArJ7PZMAAAALwBAAARAAAAAQAAAJAAAAACAAAAmAAAAAMAAADAAAAABAAA\nANgAAAAFAAAA6AAAAAYAAAAYAQAABwAAACQBAAAIAAAAOAEAAAkAAABMAQAAEgAAAFgBAAAKAAAA\neAEAAAwAAACEAQAADQAAAJABAAAOAAAAnAEAAA8AAACkAQAAEAAAAKwBAAATAAAAtAEAAAIAAADk\nBAAAHgAAACAAAABHb29nbGUgTWFwcyBLZXlib2FyZCBTaG9ydGN1dHMAAB4AAAAQAAAAV29ya2lu\nZyBhdCBOSUgAAB4AAAAIAAAATklIL09IUgAeAAAAKAAAAGdvb2dsZSwgbWFwLCBzaG9ydGN1dCwg\na2V5Ym9hcmQsIDUwOAAAAAAeAAAABAAAAAAAAAAeAAAADAAAAE5vcm1hbC5kb3RtAB4AAAAMAAAA\nZGlja2Vyc29uZ2wAHgAAAAQAAAAzAAAAHgAAABgAAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQAAABA\nAAAAAGA0PAIAAABAAAAAAKgaav8zywFAAAAAAAhPpgE0ywEDAAAAAQAAAAMAAACFAAAAAwAAANsB\nAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1Zwu\nGxCTlwgAKyz5rjAAAAAMAQAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAgAAAAAYAAACIAAAAEQAA\nAJAAAAAXAAAAmAAAAAsAAACgAAAAEAAAAKgAAAATAAAAsAAAABYAAAC4AAAADQAAAMAAAAAMAAAA\n6wAAAAIAAADkBAAAHgAAAAgAAABOSUgvT0QAAAMAAAALAAAAAwAAAAcAAAADAAAAWQIAAAMAAAAA\nAAwACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAB8AAABHb29nbGUgTWFw\ncyBLZXlib2FyZCBTaG9ydGN1dHMADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAD+////CgAAAAsA\nAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAA/v//\n/xoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAD+////IgAAACMAAAAkAAAAJQAAACYAAAAnAAAA\nKAAAAP7////9////KwAAAP7////+/////v//////////////////////////////////////////\n////////////////////////////////////////////////////////////////////////////\n////////////////////////////////////////////////////////////////////////////\n////////////////////////////////////////////////////////////////////////////\n////////////////////////////////////////////////////////////////////////////\n////////////////////////////////////////////////////////////////////////////\n//////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAA\nAAAAAAAAAADg8uKrATTLAS0AAACAAAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIB/////wUAAAD/////AAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAAFoeAAAAAAAAVwBvAHIAZABEAG8AYwB1\nAG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEBAAAA\n//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANBAAAAAAAAAF\nAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAKAACAQIAAAAEAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nABkAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0A\nYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAIQAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////////////8AAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////\n/////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAQAAAP7/////////////////////////////////////////////////////\n////////////////////////////////////////////////////////////////////////////\n////////////////////////////////////////////////////////////////////////////\n////////////////////////////////////////////////////////////////////////////\n////////////////////////////////////////////////////////////////////////////\n////////////////////////////////////////////////////////////////////////////\n////////////////////////////////////////////////////////////////////////////\n////////////////////////////////////////////////////////////////////////////\n////////////////////////////////////////////////////////////////////////////\n//////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGJwAAAE1pY3Jvc29mdCBPZmZp\nY2UgV29yZCA5Ny0yMDAzIERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQu\nOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAA=="
}'

# this should return XXXX but instead returns YYY
curl -XPOST localhost:9200/attaches/person/1 -d '{
  "query": {
    "bool": {
      "must": [
        {
          "match_all": {}
        }
      ]
    }
  }
}

This should have returned the file in base64 with other parameters (its metadata) but, instead, only the file without the metadata was returned. What am I doing wrong?

To do this:
I encoded this file:
http://hr.od.nih.gov/workingatnih/executive/docs/googlemapkeyshortcut.doc
into base64 and then replaced the newlines (\n) into the literal "\n" characters ("\n").
After that I made the PUT request to add the file.
The file is added without any errors but no metadata is placed together with the file.
I'm using the version ''1.9.0'' with the latest stable version of ElasticSearch ''0.90.5''

Mapper plugin overwrite date mapping

If you define some specific mapping for your file content, such as the following:

{
    "person": {
        "properties": {
            "file": {
                "type": "attachment",
                "path": "full",
                "fields": {
                    "date": { "type": "string" }
                }
            }
        }
    }
}

And then, if you ask back the mapping, you get:

{
   "person":{
      "properties":{
         "file":{
            "type":"attachment",
            "path":"full",
            "fields":{
               "file":{
                  "type":"string"
               },
               "author":{
                  "type":"string"
               },
               "title":{
                  "type":"string"
               },
               "name":{
                  "type":"string"
               },
               "date":{
                  "type":"date",
                  "format":"dateOptionalTime"
               },
               "keywords":{
                  "type":"string"
               },
               "content_type":{
                  "type":"string"
               }
            }
         }
      }
   }
}

All your settings have been overwrited by the mapper plugin.

See also issue #22 where the issue was found.

plugin installation Error

Hello, then I try to install plugin by command:
bin/plugin -install elasticsearch/elasticsearch-mapper-attachments/1.8.0

I have the following message:
Installed mapper-attachments into /home/elastic/plugins/mapper-attachments
Plugin installation assumed to be site plugin, but contains source code, aborting installation..

Debian and plugin

Standard installation on a Debian 6 Squeeze:

wget http://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-0.20.5.deb
dpkg -i elasticsearch-0.20.5.deb
cd /usr/share/elasticsearch
./bin/plugin -install elasticsearch/elasticsearch-mapper-attachments/1.7.0
/etc/init.d/elasticsearch restart

Try http://www.elasticsearch.org/tutorials/2011/07/18/attachment-type-in-action.html

When do an attachment mapping I get:

{"error":"RemoteTransportException[[Urich, Phil][inet[/10.0.2.15:9301]][indices/mapping/put]]; nested: MapperParsingException[No handler for type [attachment] declared on field [file]]; ","status":400}

Any help?
v.

problem with indexing arabic document

Hi all

I want to use mapper-attachment plugin to index arabic documents.

But after indexing document I can't search on it.

I think this is about arabic analyzer but when I define normal analyzer the result is same:

curl -XDELETE localhost:9200/text

curl -XPUT 'localhost:9200/text' -d '
    {
        "settings":{
            "analysis": {
                "analyzer": {
                    "khofes":{
                        "type": "pattern",
                        "pattern":"\\s+"
                    }
                }
            }
        }
    }'


curl -X PUT "localhost:9200/text/extracted/_mapping" -d '{
"extracted" : {
"properties" : {
"file" : {
"type" : "attachment",
"fields" : {
"title" : { "store" : "yes" },
"file" : { "analyzer" : "khofes", "term_vector":"with_positions_offsets", "store":"yes"}
}
}
}
}
}'

echo 'ุณู„ุงู…' > tmp

//ุณู„ุงู…: you can see it here: http://translate.google.com/#auto/en/%D8%B3%D9%84%D8%A7%D9%85

coded=`cat tmp | perl -MMIME::Base64 -ne 'print encode_base64($_)'`
json="{\"file\":\"${coded}\"}"
echo "$json" > json.file

curl -XPUT localhost:9200/text/extracted/0 -d @json.file

but when I get the content, the content is empty:

curl -XGET 'http://localhost:9200/text/_search?pretty=1'  -d '
{
  "fields": "file"
}'

So I think problem is about mapper attachment because this:

curl -XGET 'localhost:9200/text/_analyze?analyzer=khofes&pretty=true' -d `cat tmp`

and I get this:

{
  "tokens" : [ {
    "token" : "ุณู„ุงู…",
    "start_offset" : 0,
    "end_offset" : 4,
    "type" : "word",
    "position" : 1
  } ]
}

p.m: when I use:
echo 'peace' > tmp
this is works very well, So what can I do?

Thanks

possible version issue

I have elasticsearch version 0.20.5 but mapper attachment plugin 1.7 - is this an incompatible pair based on the release table in the README? Should I downgrade the plugin?

I'm getting random shard failures every few hours. The versions of java and es are the same so looking into other things.

Add option to fetch content from uri AND/OR store extracted text in _source

Our attachments can be fairly large (100MB+) and, of course, they're even bigger in base64. Storing the base64 in _source is not feasible and really not that useful. It's not human readable and most of it is format-specific metadata or images. But, excluding attachment fields from _source makes it harder to use the _update API.

I don't know how hard it would be to modify _source during indexing, but I think the direct solution to the _update issue is to simply store the Tika-extracted text in _source (in base 64 if necessary). This could be controlled by a boolean "text_only_source" option in the attachment field mapping.

Alternatively, it would be really cool if mapper-attachments accepted a URI to fetch the attachment from. This could be controlled by an option in either the field mapping or the attachment objects (whichever makes more sense). The option could be named "content_from" and accept "base64" or "uri", defaulting to "base64".

es v.0.90.9 MapperParsingException

Hi, I got GridFS working with ES, the docs are getting indexed and I can find content from within a pdf file. However, I get an exception in the process. I use mapper 1.90 and es 0.90.9 and HEAD of master of elasticsearch-river-mongodb. I use the instructions from the wiki.

I wonder if I need to set the mapping explicitly? Here is the mapping I have (from _mapping):

escms: {
files: {
properties: {
chunkSize: {
type: "long"
},
content: {
properties: {
content: {
type: "string"
},
title: {
type: "string"
}
}
},
filename: {
type: "string"
},
length: {
type: "long"
},
md5: {
type: "string"
},
metadata: {
type: "object"
},
uploadDate: {
type: "date",
format: "dateOptionalTime"
}
}
}
}

Below is the log:
[2014-01-09 02:58:18,925][INFO ][river.mongodb ] Parse river settings for mongogridfs
[2014-01-09 02:58:18,931][INFO ][river.mongodb ] Server: vps-1021944-5804.homecloud.pl - 27018
[2014-01-09 02:58:18,956][INFO ][org.elasticsearch.river.mongodb.MongoDBRiver] Starting river mongogridfs
[2014-01-09 02:58:18,992][INFO ][org.elasticsearch.river.mongodb.MongoDBRiver] MongoDB River Plugin - version[1.7.4-SNAPSHOT] - hash[ac79194] - time[2014-01-06T11:07:11Z]
[2014-01-09 02:58:19,001][INFO ][org.elasticsearch.river.mongodb.MongoDBRiver] starting mongodb stream. options: secondaryreadpreference [false], drop_collection [false], include_collection [], throttlesize [5000], gridfs [true], filter [null], db [escms], collection [fs], script [null], indexing to [escms]/[files]
[2014-01-09 02:58:19,009][INFO ][org.elasticsearch.river.mongodb.MongoDBRiver] Mapping: {"files":{"properties":{"content":{"type":"attachment"},"filename":{"type":"string"},"contentType":{"type":"string"},"md5":{"type":"string"},"length":{"type":"long"},"chunkSize":{"type":"long"}}}}
[2014-01-09 02:58:19,069][WARN ][org.elasticsearch.river.mongodb.MongoDBRiver] Failed to set explicit mapping (attachment): {}
org.elasticsearch.index.mapper.MapperParsingException: No handler for type [attachment] declared on field [content]
at org.elasticsearch.index.mapper.object.ObjectMapper$TypeParser.parseProperties(ObjectMapper.java:260)
at org.elasticsearch.index.mapper.object.ObjectMapper$TypeParser.parse(ObjectMapper.java:218)
at org.elasticsearch.index.mapper.DocumentMapperParser.parse(DocumentMapperParser.java:201)
at org.elasticsearch.index.mapper.DocumentMapperParser.parseCompressed(DocumentMapperParser.java:183)
at org.elasticsearch.index.mapper.MapperService.parse(MapperService.java:322)
at org.elasticsearch.index.mapper.MapperService.parse(MapperService.java:318)
at org.elasticsearch.cluster.metadata.MetaDataMappingService$5.execute(MetaDataMappingService.java:533)
at org.elasticsearch.cluster.service.InternalClusterService$UpdateTask.run(InternalClusterService.java:300)
at org.elasticsearch.common.util.concurrent.PrioritizedEsThreadPoolExecutor$TieBreakingPrioritizedRunnable.run(PrioritizedEsThreadPoolExecutor.java:135)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
[2014-01-09 02:58:19,317][INFO ][org.elasticsearch.river.mongodb.MongoDBRiver] MongoDB version - 2.4.8
[2014-01-09 02:58:19,370][INFO ][org.elasticsearch.river.mongodb.Slurper] MongoDBRiver is beginning initial import of escms.fs
[2014-01-09 02:58:19,991][INFO ][org.elasticsearch.river.mongodb.Indexer] Add Attachment: 52ce018ae335ab7b9fb13cc5 to index escms / type files
[2014-01-09 03:18:52,580][INFO ][org.elasticsearch.river.mongodb.Indexer] Delete request [escms], [files], [52ce018ae335ab7b9fb13cc5]
[2014-01-09 03:19:02,829][INFO ][org.elasticsearch.river.mongodb.Slurper] Caught file: 52ce0716fbcccc33f00e495a - Osho_Medytacja.pdf
[2014-01-09 03:19:02,830][INFO ][org.elasticsearch.river.mongodb.Indexer] Add Attachment: 52ce0716fbcccc33f00e495a to index escms / type files

Not indexing MS Office file content

I'm using ES with mapper-attachment to index files (such as PDF, DOC, XLS...) from a Ruby on Rails project. All the files I'm trying to index are supported by Apache Tika, and I can already index and search inside PDF files with highlighting, but not in MS documents. Is there anything I should know?

An example request:

{
"author": "jon",
"biographical_region": "",
"content_type": "application/msword",
"created_at": "2013-04-19T07:16:34Z",
"description": "",
"downloads": null,
"file": {
"url": "/uploads/tmp/20130419-0916-2319-8488/mikel.doc"
},
"file_size": 22016.0,
"geographical_coverage": "",
"id": 11,
"language": "",
"md5hash": "7b5c29584169e3c110678904cb08dd07",
"published": false,
"published_on": null,
"site_id": 1,
"source_url": "",
"theme_id": null,
"title": "Example Document",
"updated_at": "2013-04-19T07:16:34Z",
"attachment": "0M8R4KGxGuEAAAAAAAAAAAAAAAA...."
}

SL4FJ dependency version problem

Iยดm trying to use elasticsearch-mapper-attachment together with the elasticsearch-transport-couchbase plugin and get the following error:

SLF4J: The requested version 1.6 by your slf4j binding is not compatible with [1.5.5, 1.5.6]

When using either alone it works fine but not together. It seems like elasticsearch-transport-couchbase use a newer version of SLF4J, that is not compatible with the one elasticsearch-mapper-attachment uses.

Clarify index.mapping.attachment.indexed_chars

There's not a lot of information out there on indexed_chars. Just wondering if

 index.mapping.attachment.indexed_chars

would be defined in elasticsearch.yml? (If so, something is not working for me.)

Installation error on elasticsearch 1.2.0

Hello,

I'm new to elasticsearch (today!) so forgive me if I've missed something simple.

I've downloaded the elasticsearch 1.2.0 tarball, and get the following error installing the mapper-attachments plugin using the command provided in the README:

vagrant@localhost elasticsearch-1.2.0]$ bin/plugin -i elasticsearch/elasticsearch-mapper-attachments/2.0.0
-> Installing elasticsearch/elasticsearch-mapper-attachments/2.0.0...
Trying http://download.elasticsearch.org/elasticsearch/elasticsearch-mapper-attachments/elasticsearch-mapper-attachments-2.0.0.zip...
Trying http://search.maven.org/remotecontent?filepath=elasticsearch/elasticsearch-mapper-attachments/2.0.0/elasticsearch-mapper-attachments-2.0.0.zip...
Trying https://oss.sonatype.org/service/local/repositories/releases/content/elasticsearch/elasticsearch-mapper-attachments/2.0.0/elasticsearch-mapper-attachments-2.0.0.zip...
Trying https://github.com/elasticsearch/elasticsearch-mapper-attachments/archive/v2.0.0.zip...
Downloading ........................................................DONE
Installed elasticsearch/elasticsearch-mapper-attachments/2.0.0 into /home/vagrant/elasticsearch-1.1.2/plugins/mapper-attachments
Usage:
    -u, --url     [plugin location]   : Set exact URL to download the plugin from
    -i, --install [plugin name]       : Downloads and installs listed plugins [*]
    -t, --timeout [duration]          : Timeout setting: 30s, 1m, 1h... (infinite by default)
    -r, --remove  [plugin name]       : Removes listed plugins
    -l, --list                        : List installed plugins
    -v, --verbose                     : Prints verbose messages
    -s, --silent                      : Run in silent mode
    -h, --help                        : Prints this help message

 [*] Plugin name could be:
     elasticsearch/plugin/version for official elasticsearch plugins (download from download.elasticsearch.org)
     groupId/artifactId/version   for community plugins (download from maven central or oss sonatype)
     username/repository          for site plugins (download from github master)

Message:
   Error while installing plugin, reason: IllegalArgumentException: Plugin installation assumed to be site plugin, but contains source code, aborting installation.

Any ideas?

M

Adding OCR support

Heya,

Would be nice to have an OCR support for images and if possible PDF files.
I would be pleased to contribute for it but I could not find a nice OCR Java library available in a maven repo. Any idea ?

Perhaps, we could activate this option as follow:

{
    "person" : {
        "properties" : {
            "file" : { 
                "type" : "attachment",
                "ocr" : {
                   "activate" : true,
                   "otheroption.........." : "value"
                },
                "fields" : {
                    "file" : {"index" : "no"},
                    "date" : {"store" : "yes"},
                    "author" : {"analyzer" : "myAnalyzer"}
                }
            }
        }
    }
}

What do you think ? Is the best place to support this option ? Should it be part of another plugin ?

Tika may "hang up" client application

Sometimes Tika may crash while parsing some files. In this case it may generate just runtime errors (Throwable), not TikaException.
But there is no โ€œcatchโ€ clause for Throwable in the AttachmentMapper.java :

    String parsedContent;
    try {
        // Set the maximum length of strings returned by the parseToString method, -1 sets no limit            
        parsedContent = tika().parseToString(new FastByteArrayInputStream(content), metadata, indexedChars);
    } catch (TikaException e) {
        throw new MapperParsingException("Failed to extract [" + indexedChars + "] characters of text for [" + name + "]", e);
    }

As a result, tika() may โ€œhang upโ€ the whole application.
(we have some pdf-files that "hang up" Elastic client if you try to parse them using mapper-attahcment plugin)

We propose the following fix:

    String parsedContent;
    try {
        // Set the maximum length of strings returned by the parseToString method, -1 sets no limit            
        parsedContent = tika().parseToString(new FastByteArrayInputStream(content), metadata, indexedChars);
    } catch (Throwable e) {
        throw new MapperParsingException("Failed to extract [" + indexedChars + "] characters of text for [" + name + "]", e);
    }

(just replace โ€œTikaExceptionโ€ with โ€œThrowableโ€ โ€“ it works for our cases)

Thank you!

Mapper 1.7.0 does not work with elasticsearch 0.90.3

Hello, I updated to elasticsearch 0.90.3 and now I have an error then try to create index with attachment-type here mapping:

curl -XPUT "http://$EL_IP:9200/docs/extern/_mapping" -d '{
        "extern": {
                        "properties" : {
                                        "url" : { "type" : "string"},
                                        "file_name" : { "type" : "string"},
                                        "file_info" : { "type" : "string"},
                                        "file_hash" : { "type" : "string"},
                                        "file_type" : { "type" : "string"},
                                        "meta" : { "type" : "string"},
                                        "path" : { "type" : "string"},
                                        "summary" : {
                                                                        "type" : "attachment",
                                                                        "fields" : {
                                                                                        "file" : {"index" : "no"},
                                                                                        "date" : {"store" : "yes"}
                                                                        }
                                                        },
                                        "tic" : { "type" : "integer", "index" : "no" },
                                        "last_processed" : { "type" : "date", "index" : "no" }
                        }
        }
}'

and here an error:

 {"error":"NoClassDefFoundError[org/elasticsearch/common/io/FastByteArrayInputStream]; nested: ClassNotFoundException[org.elasticsearch.common.io.FastByteArrayInputStream]; ","status":500}

and here data from logs:

java.lang.NoClassDefFoundError: org/elasticsearch/common/io/FastByteArrayInputStream
        at org.elasticsearch.index.mapper.attachment.AttachmentMapper$Builder.build(AttachmentMapper.java:164)
        at org.elasticsearch.index.mapper.attachment.AttachmentMapper$Builder.build(AttachmentMapper.java:66)
        at org.elasticsearch.index.mapper.object.ObjectMapper$Builder.build(ObjectMapper.java:164)
        at org.elasticsearch.index.mapper.DocumentMapper$Builder.<init>(DocumentMapper.java:155)
        at org.elasticsearch.index.mapper.MapperBuilders.doc(MapperBuilders.java:45)
        at org.elasticsearch.index.mapper.DocumentMapperParser.parse(DocumentMapperParser.java:177)
        at org.elasticsearch.index.mapper.MapperService.parse(MapperService.java:380)
        at org.elasticsearch.index.mapper.MapperService.parse(MapperService.java:376)
        at org.elasticsearch.cluster.metadata.MetaDataMappingService$4.execute(MetaDataMappingService.java:389)
        at org.elasticsearch.cluster.service.InternalClusterService$UpdateTask.run(InternalClusterService.java:285)
        at org.elasticsearch.common.util.concurrent.PrioritizedEsThreadPoolExecutor$TieBreakingPrioritizedRunnable.run(PrioritizedEsThreadPoolExecutor.java:143)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:724)
Caused by: java.lang.ClassNotFoundException: org.elasticsearch.common.io.FastByteArrayInputStream
        at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        ... 14 more

in elasticsearch 0.90.2 all works fine...

P/S OS FreeBSD,

Mapper Attachements should log errors raised by Tika and proceed with indexing other fields in the index mapping

We were using mapper attachements plugin to index file content and we noticed a few errors with respect to Tika not being able to extract content. What we also noticed is that elasticsearch ignores the whole document from the index because Tika raised an error and failed. What we would like to have is an configurable option for elasticsearch to proceed with document indexing even if the file extraction through the mapper-attachments failed.

Error creating mapping

I have the next config:

  • ElasticSearch 0.90.3
  • Mapper Attachments Type 0.90.3

I do the next:

  1. Creating index:
    curl -X PUT "localhost:9200/test" -d '{
    "settings" : { "index" : { "number_of_shards" : 1, "number_of_replicas" : 0 }}
    }'

2.Create the mapping:
curl -X PUT "localhost:9200/test/attachment/_mapping" -d '{
"attachment" : {
"properties" : {
"file" : {
"type" : "attachment"
}
}
}
}'

I get the next error:
{"error":"RemoteTransportException[Failed to deserialize exception response from stream]; nested: TransportSerializationException[Failed to deserialize exception response from stream]; nested: EOFException; ","status":500}

I can't see any error in the log.

Failed to index metadata for epub

Dear all,

I suspect there is a bug in the interaction with apache tika-app when dealing with epub.

Here are the steps you can reproduce to stres the suspected bug. Please correct me if I missed something. In case this this bug report is a false positive, this still could serve as an "how-to" for the citizen. I simplified the example as much as possible (no analyzer on purpose).

Given the following free epub : https://github.com/downloads/ieure/sicp/sicp.epub

If I run apache tika-app for metadata, I run the following command :

java -jar tika-app-1.3.jar -m sicp.epub 

That outputs :

Author: Harold Abelson and Gerald Jay Sussman with Julie Sussman
Content-Length: 1211674
Content-Type: application/epub+zip
creator: Harold Abelson and Gerald Jay Sussman with Julie Sussman
dc:creator: Harold Abelson and Gerald Jay Sussman with Julie Sussman
dc:identifier: 0-262-01153-0
dc:language: en-US
dc:publisher: MIT Press
dc:rights: Creative Commons Attribution-Noncommercial 3.0 Unported License.
dc:title: Structure and Interpretation of Computer Programs
identifier: 0-262-01153-0
language: en-US
meta:author: Harold Abelson and Gerald Jay Sussman with Julie Sussman
publisher: MIT Press
resourceName: sicp.epub
rights: Creative Commons Attribution-Noncommercial 3.0 Unported License.
title: Structure and Interpretation of Computer Programs

This is good.

Now Let us aim at indexing it in Elastic search.

First, create our mapping. Here is what I am using inside a bash script :

host=localhost:9200
curl -X DELETE "${host}/myepubcontents"
curl -X GET "${host}/_cluster/health?wait_for_status=green&pretty=1&timeout=5s"
curl -X PUT "${host}/myepubcontents" -d '{
  "settings" : { 
        "index" : { "number_of_shards" : 5, "number_of_replicas" : 0 }
    }
  }
}'

curl -X PUT "${host}/myepubcontents/books/_mapping" -d '{
  "books" : {
    "_all" : {"enabled" : false},
    "properties" : {
      "file" : {
          "type" : "attachment",
          "fields" : {
            "date": { "store": "yes" },
            "author": { "store": "yes" },
            "title" : { "store" : "yes" },
            "file" : { "store":"yes" }
          }
      }
    }
  }
}'

Now that my elastic search got mappings, I will push the epub to it. For this, we need to encode in base 64 and send it via a curl. Given limitation of curl, we need to serialise the base64 encoded content in a file on the filesystem, then use this file as an argument to curl. Here is how I proceed (for the sake of the example, I ran the command in a bash interpreter, outside any batch script) :

coded=`cat sicp.epub | perl -MMIME::Base64 -ne 'print encode_base64($_)'`
echo "{\"file\":\"${coded}\"}" > sicp-b64.json
curl -X POST "localhost:9200/myepubcontents/books" -d @sicp-b64.json

I know want to query ElasticSearch for this content. Here is my query :

curl -XGET 'http://localhost:9200/myepubcontents/books/_search?pretty=true&explain=false' -d '{ "fields" : [ "title", "author", "date" ],
   "query": {
      "query_string" : {
         "fields" : ["file", "title", "author" ],
         "query" : "a*",
         "use_dis_max" : true }
   },
   "highlight" : {
      "fields" : {
         "file" : {}
      }
    }
}'

It outputs :

{
  "took" : 118,
  "timed_out" : false,
  "_shards" : {
    "total" : 5,
    "successful" : 5,
    "failed" : 0
  },
  "hits" : {
    "total" : 1,
    "max_score" : 1.0,
    "hits" : [ {
      "_index" : "myepubcontents",
      "_type" : "books",
      "_id" : "C0eqQD7iRLeb5HBhYoFeeA",
      "_score" : 1.0,
      "highlight" : {
        "file" : [ " numbers.\n<em>Also</em>, in real computers, <em>arithmetic</em> operations are <em>almost</em> <em>always</em>\nperformed with limited", " we are <em>asked</em> to <em>apply</em> the procedure to some\n<em>argument</em>, we first look to see if the value is <em>already</em>", " <em>advantages</em>, however.  One of\nthem is that it can <em>accommodate</em> procedures that may take an <em>arbitrary</em>", "\n\n\n\n\n\n\nNo <em>ambiguity</em> can <em>arise</em>, because the operator is <em>always</em> the leftmost\nelement and the entire", " <em>appear</em> in\n<em>any</em> powerful programming language:\n\n\n\n\n\n\n\n\n\t\tNumbers and <em>arithmetic</em> operations are\nprimitive" ]
      }
    } ]
  }
}

Basically, I expected metadata such as author, date and title to pop as attributes within the scope of "fields" on the previous json snip.

I tried with lot of epub files, and I found none that were correctly indexed, speaking of there metadata.

  • Are all my epub broken ?
  • Or are my mappings broken somewhere ?
  • Or do you believe this can possibly be a bug in using tika-app within mapper-attachement plugin ?

Thanks in advance,
@cgravier

Fix dependency to tika-app

I don't think the pom should declare a dependency on tika-app: it is a standalone app, and is not meant to be embedded as a library.
A dependency on tika-parsers may be enough, although this should of course be tested.

The current situation is bad, because when you add elasticsearch-mapper-attachments as a dependency, you get many libs you may not want (slf4j, bouncycastle, etc.) without the possibility to exclude or upgrade them.

(This originally comes from a tweet by @fcamblor : https://twitter.com/fcamblor/status/251305092718931968 ;-)

Not able to index file content by using mapper attachment

Hello,

I have created a mapping with attachment type as below:

curl -XPUT "localhost:9200/esindex/es_pdfs/_mapping" -d '
{
"es_pdfs" : {
"dynamic_templates" : [
{
{
"my_attachment" : {
"match" : "my_attachment",
"mapping" : {
"type" : "attachment",
"fields" : {
"file" : { "index" : "yes"},
"title" : { "store" : "yes" },
"date" : { "store" : "yes" },
"author" : { "store" : "yes" },
"keywords" : { "store" : "yes" },
"content_type" : { "store" : "yes" },
"content_length" : { "store" : "yes" }
}}
}}]
}
}'

And then created a river as below:

curl -XPUT 'localhost:9200/_river/es_pdfs/_meta?pretty' -d '{
"type" : "web",
"crawl" : {
"index" : "esindex",
"url" : "http://...",
...
"target" : [
...
{
"pattern" : {
"url" : "http://.../.*"
},
"properties" : {
"my_attachment" : {
"type" : "attachment"
}
}
}
]
...

But it could not index file content and throwing error as below:

DEBUG][action.index ] [Intermec] [esindex][3], node[mQLKRDbqSuue_RwJGbcJSw], [P], s[STARTED]: Failed to execute [index {[esindex][es_pdfs][h6mK_aHhSBuIRHLRZ74W_w], source[{"method":"GET","lastModified":"2007-06-12T16:36:01.000Z","contentLength":42116,"url":"http://www.intermec.es/about_us/newsroom/press_releases/files/92.pdf","charSet":"UTF-8","mimeType":"application/pdf","parentUrl":"http://www.intermec.es/about_us/newsroom/press_releases/pb42_08_2006.aspx","httpStatusCode":200,"executionTime":32,"my_attachment":"JVBERi0xLjQNJeLjz9MNCjExNCAwIG9iajw8L0hbMTEzNyAyODJdL0xpbmVhcml6ZWQgMS9FIDMwNTkxL0wgNDIxMTYvTiAyL08......................iUlRU9GDQo=","@timestamp":"2014-03-28T12:29:38.714Z"}]}]
org.elasticsearch.index.mapper.MapperParsingException: failed to find type parsed [attachment] for [my_attachment]
at org.elasticsearch.index.mapper.object.RootObjectMapper.findTemplateBuilder(RootObjectMapper.java:212)
at org.elasticsearch.index.mapper.object.ObjectMapper.parseDynamicValue(ObjectMapper.java:647)
at org.elasticsearch.index.mapper.object.ObjectMapper.serializeValue(ObjectMapper.java:618)
at org.elasticsearch.index.mapper.object.ObjectMapper.parse(ObjectMapper.java:469)
at org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper.java:515)
at org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper.java:462)
at org.elasticsearch.index.shard.service.InternalIndexShard.prepareCreate(InternalIndexShard.java:371)
at org.elasticsearch.action.index.TransportIndexAction.shardOperationOnPrimary(TransportIndexAction.java:215)
at org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction.performOnPrimary(TransportShardReplicationOperationAction.java:556)
at org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction$1.run(TransportShardReplicationOperationAction.java:426)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
[2014-03-28 12:29:38,716][WARN ][org.codelibs.elasticsearch.web.robot.transformer.ScrapingTransformer] Could not write a content into index.
org.elasticsearch.index.mapper.MapperParsingException: failed to find type parsed [attachment] for [my_attachment]

Can anyone help me on this as I need to index all my PDFs including its content. And without using attachment mapper I am able to index pdfs content but which is of no use as it is all junk stuff...!

Thanks,
Srinivas V

Parsing of application/ms-tnef type is incorrect

When indexing a TNEF document, The contents of the winmail.dat attachment are not searchable, even though Tika 1.4 has a TnefParser and (I think) is being run on the document. The index returns a content type of message/rfc822 when indexing an email containing a winmail.dat attachment, or text/plain; charset=windows-1252 when indexing the raw attachment.

Both of these types are incorrect, the content type is application/ms-tnef, and the attachment content remains in base64 and isn't searchable. I have tested this on plugin version 1.9.0 with es 0.9.11

extracted plain text

is it posible to access/index extracted plain text from tika in ES via REST API?
possible under "_text" field after enabling this functionality?
this would be helpful for backwards checks.

Mapper plugin overwrites multifield mapping

If you define some specific mapping for your file content, such as the following:

{
    "person": {
        "properties": {
            "file": {
                "type": "attachment",
                "path": "full",
                "fields": {
                    "file": {
                        "type": "multifield",
                        "fields": {
                            "file": { "type": "string" },
                            "suggest": { "type": "string" }
                        }
                    }
                }
            }
        }
    }
}

And then, if you ask back the mapping, you get:

{
   "person":{
      "properties":{
         "file":{
            "type":"attachment",
            "path":"full",
            "fields":{
               "file":{
                  "type":"string"
               },
               "author":{
                  "type":"string"
               },
               "title":{
                  "type":"string"
               },
               "name":{
                  "type":"string"
               },
               "date":{
                  "type":"date",
                  "format":"dateOptionalTime"
               },
               "keywords":{
                  "type":"string"
               },
               "content_type":{
                  "type":"string"
               }
            }
         }
      }
   }
}

All your settings have been overwrited by the mapper plugin.

Don't reject full document in case of invalid metadata

From original PR #17 from @fcamblor

If you try to index a document with an invalid metadata, the full document is rejected.

For example:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/html4/loose.dtd">
<html lang="fr">
<head>
    <title>Hello</title>
    <meta name="date" content="">
    <meta name="Author" content="kimchy">
    <meta name="Keywords" content="elasticsearch,cool,bonsai">
</head>
<body>World</body>
</html>

has a non parseable date.

This fix add a new option that ignore parsing errors "index.mapping.attachment.ignore_errors":true (default to true).

Store attachment tika-extracted meta data fields in _source

This is more of an enhancement. Currently, fields like .author, .title, etc.. are stored by default and field.author, field.title are base64 so when these fields (using field dot notation field.title, field.author) are requested via a search request, it brings back the full base64 of the attachment instead of just the meta data field string value. Would be nice for the plugin to store the metadata field values directly in the source.

highlighting documentation

I think adding a section to the README about highlighting with an example would be great. It took me awhile to figure out the correct syntax. Based on threads on the mailing list and stackoverflow, I suspect the missing piece of information is that you need to use the field's name when setting the type of highlighter which isn't obvious at least for me. At least that is true for version 1.9.0 of the plugin.

From https://gist.github.com/dadoonet/3907010

curl -X PUT "${host}/test/attachment/_mapping" -d '{
    "attachment" : {
        "properties" : {
            "file" : {
                "type" : "attachment",
                "fields" : {
                    "title" : { "store" : "yes" },
                    "file" : { "term_vector":"with_positions_offsets", "store":"yes" }
                }
            }
        }
    }
}'

Since file is such a generic name, I thought that meant I should do the following:

curl -X PUT "${host}/test/my_type/_mapping" -d '{
    "my_type" : {
        "properties" : {
            "my_html_file" : {
                "type" : "attachment",
                "fields" : {
                    "title" : { "store" : "yes" },
                    "file" : { "term_vector":"with_positions_offsets", "store":"yes" }
                }
            }
        }
    }
}'

Instead this worked:

curl -X PUT "${host}/test/my_type/_mapping" -d '{
    "my_type" : {
        "properties" : {
            "my_html_file" : {
                "type" : "attachment",
                "fields" : {
                    "title" : { "store" : "yes" },
                    "my_html_file" : { "term_vector":"with_positions_offsets", "store":"yes" }
                }
            }
        }
    }
}'

NodesNamespace problem with info() function

Hello,

I'm writing a function and I want to get all installed plugins.
I'm using the following line, where $client is a parameter of type \Elasticsearch\Client

$client->nodes()->info(array('node_id' => '_all', 'plugin' => TRUE));

This code is throwing this error: plugin is not a valid parameter
I've tried also with 'plugins' but the result is the same.
In the function comments it is written that this is the right syntax.

Ignore encrypted documents

I am sending multiple pdf, word etc. attachments in one documents to be indexed.

Some of them (pdf) are encrypted and I am getting a MapperParsingException caused by org.apache.tika.exception.TikaException: Unable to extract PDF content cause by
org.apache.pdfbox.exceptions.WrappedIOException: Error decrypting document.

I was wondering if the attachment mapper could expose some switch to ignore the documents it can not extract?

Just store plain text

Is it possible to not store the base64 encoding of the file, and just store the extracted text?

NPE if "content" is missing in mapper-attachment plugin

This issue comes from elastic/elasticsearch#238

Curl recreation:

curl -X DELETE "localhost:9200/test"

curl -X PUT "localhost:9200/test" -d '{
  "settings" : { "index" : { "number_of_shards" : 1, "number_of_replicas" : 0 }}
}'

curl -X GET "localhost:9200/_cluster/health?wait_for_status=green&pretty=1&timeout=5s"

curl -X PUT "localhost:9200/test/attachment/_mapping" -d '{
  "attachment" : {
    "properties" : {
      "file" : {
        "type" : "attachment"
      }
    }
  }
}'

curl -X PUT "localhost:9200/test/attachment/1" -d '{
    "file" : {
        "_content_type" : "application/pdf",
        "_name" : "resource/name/of/my.pdf"
    }
}
'

Produces a:

{"error":"NullPointerException[null]","status":500}

And in ES logs:

[2013-02-20 12:49:04,445][DEBUG][action.index             ] [Drake, Frank] [test][0], node[LI6crwNKQmu1ue1u7mlqGA], [P], s[STARTED]: Failed to execute [index {[test][attachment][1], source[{
    "file" : {
        "_content_type" : "application/pdf",
        "_name" : "resource/name/of/my.pdf"
    }
}
]}]
java.lang.NullPointerException
    at org.elasticsearch.common.io.FastByteArrayInputStream.<init>(FastByteArrayInputStream.java:90)
    at org.elasticsearch.index.mapper.attachment.AttachmentMapper.parse(AttachmentMapper.java:309)
    at org.elasticsearch.index.mapper.object.ObjectMapper.serializeObject(ObjectMapper.java:507)
    at org.elasticsearch.index.mapper.object.ObjectMapper.parse(ObjectMapper.java:449)
    at org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper.java:486)
    at org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper.java:430)
    at org.elasticsearch.index.shard.service.InternalIndexShard.prepareIndex(InternalIndexShard.java:318)
    at org.elasticsearch.action.index.TransportIndexAction.shardOperationOnPrimary(TransportIndexAction.java:203)
    at org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction.performOnPrimary(TransportShardReplicationOperationAction.java:531)
    at org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction$1.run(TransportShardReplicationOperationAction.java:429)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:680)

save all tika metadata

Would be great to have the ability to save all the metadata returned from tika instead of just getting: title, author, keywords, date, content_type
loop through metada.names()
or
maybe use this JsonHelper which returns the metadata as a JSON
https://issues.apache.org/jira/secure/attachment/12476761/JSONHelper.java.

I also noticed that if one does not define the fields they do not get saved.
if i only define title i will not get author, date, keywords, content_type.

Thanks

FastByteArrayInputStream NoClassDefFound

When I try to create my index I get an error:

curl -XPUT 'http://localhost:9200/article/_mapping' -d'
{:article=>{:properties=>{:attachment=>{:type=>"attachment"}}}}}'
{"error": "ActionRequestValidationException[Validation Failed: 1: mapping type is missing;]",
 "status":500}%

Using elasticsearch 0.90.3, tika 1.4 and elasticsearch-mapper-attachments 1.9.0

Unsupported date format while parsing Exchange Emails

This format showed up while parsing a bunch of our customers' data:

Caused by: org.elasticsearch.index.mapper.MapperParsingException: failed to parse date 
field [16 Aug 2010 13:20:42 +0200], tried both date format [dateOptionalTime], and 
timestamp number0

It is keeping a bunch of our emails from getting parsed. Sadness!

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.