The DocumentMapper is located at server side or in a plugin when the request of a client is processed. It is not possible to use it by clients to bypass the ES API. The communication to the nodes that receive document mapper requests is very low level and beyond the ES API - see the transport shard actions.
In ES, the XContent universal helper classes wrap all possible formats, like SMILE or YAML, on the ES API and for internal transmissions too. Compressed JSON is used for data transmission. Unless exceptions, no Java object serialization is used. In my eyes it is one of the strengths of XContent to construct arbitrary JSON-like object/array streams without a schema. You don't have to care about JSON strings at all. It is a natural fluent API that helps a lot in writing correct code (if your IDE uses code completion). The alternative would be a static approach where every action class would carry its own parameterization and serialization scheme. This is one area where ES really shines - it has a dynamic parameterization, XContent can drive new actions and existent actions as well. The price is missing validation at code writing time, but I don't miss such a thing. Jörg On Fri, Mar 28, 2014 at 10:20 PM, Jacob Stultz <[email protected]> wrote: > I'm wondering how feasible it is to use some of the Java classes defined > by Elasticsearch on the client side, rather than building up JSON strings > or XContentBuilder instances manually. Specifically, I'm wondering about > creating mappings. It would be really nice if I could create a > DocumentMapper instance (which implements ToXContent) to define a mapping, > and then use that to create an XContentBuilder to pass to setSource on > PutMappingRequestBuilder. > > This would be great, since it would rely on existing types to ensure that > valid mappings are created, rather than leaving open the possibility of > incorrectly constructing JSON (either via typos or incorrect field names, > or just incorrect structure). > > However, I'm having trouble figuring out whether this is possible or > intended; it seems to create a DocumentMapper instance, I'd need a > DocumentMapper.Builder instance, which requires a DocumentMapperParser > instance to build the DocumentMapper, and the DocumentMapperParser instance > in turn requires a number of other objects not readily available. > > Am I basically stuck with writing my own code to generate these JSON > structures? If so, it'd be really nice in the future if the Java API would > leverage the fact that much of the code is already used on the server side, > and make those classes easily available for clients to leverage static > typing to help ensure correctness. > > Thanks. > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/8cbf0f15-a5d2-4dda-9759-ede3505ca08e%40googlegroups.com<https://groups.google.com/d/msgid/elasticsearch/8cbf0f15-a5d2-4dda-9759-ede3505ca08e%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFD%3DoSJTL2Uzw%2B5Acwm9Lrdk6VueM-%2BRJj%3DPu2zX9zH0w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
