[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: 

  1. We don't necessarily have a POJO for the Objects we are decoding/encoding.
  2. Event If we have generated code, the EMF Objects should not be used via the normal java reflections.

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.

Generated at Thu Feb 08 08:57:22 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.