[JAVA-2495] Provide a more extensible DecoderContext and EncoderContext Created: 18/Apr/17 Updated: 29/Jan/19 Resolved: 29/Jan/19 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | Codecs |
| Affects Version/s: | 3.4.2 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Jürgen Albert | Assignee: | Ross Lawley |
| Resolution: | Won't Fix | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
It would be nice to have a decoder and encoder context, that can be used externally, to pass options to the decoder and encoder. Right now I see no possibility to modify the existing context, overwrite it with some custom attributes, or even a possibility to hand over a own context implementation. The suggestion would be to ether make both contexts and there builders public and extensible or to provide a options map, that can be used and set for each child context. Either way would require some handover at the collection class as well, like find(<the findparameters>, DecoderContext) or find(<the findparameters>, Map<Object, Object>) "What is the usecase?" We have generic Decoder and Encoder, that works with an EMF model as a schema, with can take a couple of options, like a flag to serialize default values or not. Right now we have to instantiate a CodecProvider for every find we make in order to hand some options to the codec we want to use. Furthermore we call the codec registry and decode for every containment reference. We know the type for every containment reference and what type to expect, this we need to hand to our child decoder that is generic as well. Right now our Codec is not stateless and we have a instance for every find operation, which is kind of bad. With the above mentioned mechanism we could get rid of it. |
| Comments |
| Comment by Jürgen Albert [ 29/Jan/19 ] |
|
PojoCodec is nice, but we can't use it. We use EMF and thus a model driven approach. This means 2 Things:
In Addition to this, we have a couple of things we want/need to pass to the codec. This are e.g. the above mentioned options, factories and model repositories. We could get rid of a lot of code, if we could simply provide our own context as an extension to the Decoder-/EncoderContext. Additionally, we could finally make our Codec stateles. We don't need anything fancy. It wouöld suffice, if we would be able to extend the contexts themself. You are using the context for yourself in the PojoCodec and it would be nice to give us the same possibility. |
| Comment by Ross Lawley [ 29/Jan/19 ] |
|
Having discussed internally, we've decided to mark this ticket as "Won't Fix". I understand the motivations for the ticket but since this ticket was filed, the Java driver has introduced a PojoCodec implementation. As the PojoCodec and the rest of the driver don't need to extend these contexts, we've decided not to add it into the driver. If you or any others reading this ticket, feel strongly that this is the wrong decision, then please comment and if there is enough interest we will reconsider. |
| Comment by Michael Weber [ 30/Aug/18 ] |
|
I also need to "loop through" some context when decoding nested structures. I like the idea of having a map inside DecoderContext that can be used to hold context. |