Mapping Serialiser

[KodrAus]

Create a trait for getting the mapping configuration for some struct as JSON, follow a similar idea to serde; we visit the fields on the given struct, and build up a mapping as we go.

For example:

[derive(elastic_mapping(name("my_type")))]
struct MyType {
    [derive(elastic_mapping(analyzer("my_custom_analyser"), index(true)))]
    title: String,
    date: DateTime<BasicDateTime>
}

Could be compiled to something like:

struct MyType {
   ...
}

impl ElasticStruct for MyType {
    fn type_name(&self) -> &'static str {
        "my_type"
    }
}

impl ElasticMapping for MyType {
    fn map<'a>(&'a self) -> &'a str {
        //Iterate over properties, map and stuff
    }
}

The result of map would be like:

{
    "properties": {
        "title: {
            "type": "string",
            "analyzer": "my_custom_analyser",
            "index": true
       },
       "date": {
           "type": "date",
           "format": "basic_date_time"
       }
   }
}

[KodrAus]

Need to figure out how to deal with things like Strings. The properties above are given as an attribute, whereas with DateTime, the format is a first-class citizen, even though it's technically no more special than the analyzer on the String.

It'd be nice to keep things consistent, but also simple, it'd be dumb to invent a new String type, but it should also all tie in with the DateTime stuff.

[KodrAus]

There've been a bunch of commits in this space in the last few days. Things are coming along nicely. The basic design is:

• ElasticMapping<F> where F is an optional extra type (like Format on DateTime). It defaults to unit.
• Each core type is related to its own Elastic*Mapping trait, that contains the possible mapping fields that a user can override.
• Implementing the Elastic*Mapping trait means also implementing serde::Serialize, which is responsible for converting the trait to a valid json representation for Elasticsearch.
• We need some way of auto implementing the serialization part, because that doesn't need to change for each mapping.

[KodrAus]

The mapping design needs to be tidied up. It makers sense to keep mapping for core types together with the type impl, but for an end-user, the mapping should all be collected in a single place.

Stick the contents of *::mapping::* in ::mapping::*, so it's not clogging up the implementation stuff, but is also easily accessible.

[KodrAus]

This is looking pretty good, the rest is up to #59 to make it easy to derive the mapping serialisation.