Is it possible in NEST / Elasticsearch-net 5.5 to make a custom serializer to only work on my own app's defined types and let the built in serializer handle the rest of Elastic packages own types?
I would like to accomplish this because my custom serializer is failing to serialize Elasticsearch NEST queries to json string.
It's possible to define your own JSON.NET serializer with 5.x that will serialize NEST types correctly, and serialize your own types however you like too. It's not so straightforward to do however, which is why JSON.NET was internalized in NEST 6.x :) If you're not using Json.NET, you'll need to do much more work in implementing your own serializer to do this, as your serializer will also need to know how to serialize NEST types.
For this to work in 5.x, your IContractResolver must derive from ElasticContractResolver to be able to inherit serialization of NEST types. The easier way to inherit however is to derive from JsonNetSerializer and implement the behaviour that you require in a way that does not globally affect all types that will be handled by the serializer.
Related
I can't find any explanation about difference between jackson's ObjectMapper to other mappers like dozer/mapStruct/modelMapping/etc. All the articles compare dozer/mapStruct/modelMapping but they ignore ObjectMapper. I can't understand what is wrong? Is the same mapper?
Dozer, MapStruct and ModelMapping are Java Bean to Java Bean mappers frameworks that recursively copies data from one object to another, property by property, field by field.
From other side, ObjectMapper provides functionality for reading and writing JSON, either to and from basic POJOs, or to and from a general-purpose JSON Tree Model. ObjectMapper has some additional features like converting objects (see convertValue method) but it is not a main reason why this class was created.
So, if you want to implement sophisticated mapping between two different models you should use mappers; if you want to serialise model to JSON or deserialise model from JSON payload you have to use ObjectMapper from Jackson.
Jackson library- Mainly concerned with converting Objects/ Entities to JSON and back.
ModelMapper/ MapStruct - Concerned with mapping One entity to another like, mapping an Entity to its DTO. This operation can get pretty gnarly owing to the size and complexity of different entities, so we need these libraries to make work easier.
I need to provide a different version of response object for the same existing URI. I am going with Accept/Content-type conneg methodologies. I am using Jackson to covert my POJO into json. please help me how should i do it with jackson.
for the object model, must i have a base class and object versions are extended class?
Instead of having one object that would be serialized in two different ways, I'd recommend using two separate DTOs. One for each version.
The content negotiation will happen not on Jackson's side, but on the JAX-RS side with the #Produces annotation.
One method returning DTOv1 will produce application/vnd.v1+json while the other will return DTOv2 with application/vnd.v2+json.
I'm trying to do some polymorphic deseralization of JSON using Jackson, however the list of subclasses is unknown at compile time, so I can't use a #JsonSubtype annotation on the base class.
Instead I want to use a TypeIdResolver class to perform the conversion to and from a property value.
The list of possible subclasses I might encounter will be dynamic, but they are all registered at run time with a registry. So I would appear to need my TypeIdResolver object to have a reference to that registry class. It has to operate in what is essentially a dependency injection environment (i.e I can't have a singleton class that the TypeIdResolver consults), so I think I need to inject the registry class into the TypeIdResolver. The kind of code I think I want write is:
ObjectMapper mapper = new ObjectMapper();
mapper.something(new MyTypeIdResolver(subclassRegistry));
mapper.readValue(...)
However, I can't find a way of doing the bit in the middle. The only methods I can find use java annotations to specify what the TypeIdResolver is going to be.
This question Is there a way to specify #JsonTypeIdResolver on mapper config instead of annotation? is the same, though the motivation is different, and the answer is to use an annotation mixin, which won't work here.
SimpleModule has method registerSubtypes(), with which you can register subtypes. If only passing Classes, simple class name is used as type id, but you can also pass NamedType to define type id to use for sub-class.
So, if you do know full set, just build SimpleModule, register that to mapper.
Otherwise if this does not work you may need to resort to just sharing data via static singleton instance (if applicable), or even ThreadLocal.
Note that in the end what I did was abandon Jackson and write my own much simpler framework based on javax.json that just did the kinds of serialisation I wanted in a much more straightforward fashion. I was only dealing with simple DTO (data transfer object) classes, so it was just much simpler to write my own simple framework.
I need to serialize some complex interface (template.Template). It has many unexported fields, and gob don't want to work with them. Any suggestions?
P.S. Actualy, I trying to put a parsed template to memcache on App Engine.
The short answer is that there's usually a reason for unexported fields--template.Template, for instance, contains information which changes during parsing--so I'd advise against serializing them yourself with reflect. However, the GobEncoder and GobDecoder interfaces were recently added to gob; if you need to serialize a complex struct with unexported fields, encourage the author of the package to implement these interfaces. Even better, implement them yourself (shouldn't be hard for template.Template) and contribute your patch.
If the type is from another package (such as template) this can't be done with any of the current serialization libs for Go (gob, json, bson, etc.). Nor should it be done, because the fields are unexported.
However, if you really need to, you can write your own serializer using package reflect, specifically Value.Field() and friends to get the unexported fields. Then you just need to store them in a way that you can decode later.
Can anyone please elabortae me the reasons why should I use Data Contract Serializer
while we have XML/Binary serializer already there in .Net ?
This is a site i found when i was looking into the same issue.
You should check this out
Quoting from the same link mentioned above:
Advantages of DataContractSerializer over XMLSerializer
Opt-in rather than opt-out properties to serialize.
Because it is opt in you can serialize not only properties, but also fields. You can even serialize non-public members such as private or protected members. And you dont need a set on a property either (however without a setter you can serialize, but not deserialize)
Is about 10% faster than XmlSerializer to serialize the data because since you don’t have full control over how it is serialize, there is a lot that can be done to optimize the serialization/deserialization process.
Can understand the SerializableAttribute and know that it needs to be serialized
More options and control over KnownTypes
Hope it helps!
One more HUGE advantage; DataContract serialization allows for interop between any two classes that implement the same DataContract. This is what allows WCF to generate the data classes for you automatically when you reference a WCF service. You can also "hack" this process by referencing a published DataContract in a new user-developed class (or two or three); You can then transfer data between instances of these classes, and any other new ones you create, via serialization. This is also possible but much more difficult with XML serialization, and impossible with binary serialization.