How to properly register a org.bson.codecs.Codec in 2.3.0?

[zenbones]

I have a class that requires a custom codec. I used to 'register' these in 1.32. by creating a TypeConverter and using @converters(). I think now I should be creating a Codec, but what's the proper way to register such a codec in 2.3.0?

[evanchooly]

You'd provide a CodecProvider via dev.morphia.mapping.MapperOptions.Builder#codecProvider. You can see an example here.

[zenbones]

Thanks, I did figure this out. As I've noted previously, a @CodecProvider annotation would be nicer. Everything else works via annotation, and if you can find and use all of those, registering a class annotated with @CodecProvider (Class<?> for which conversion is provided) seems nicer. And as long as we're on that, the actual codecs are kind of a pain. Working directly with BsonReader and BsonWriter means figuring out how reading/writing types, names and values works. Not rocket science, but still awkward. Would be nicer to take maybe a BsonValue and return an instance of type, and take such an instance and return a BsonValue to be written to the db. I think in part not having a canonical json representation with a nice interface is what's missing. Jackson used to suffer from the same problem before institutionalizing JsonNode as its canonical representation.

[evanchooly]

I actually some internal types that make writing out those document structures much more DSLish. I've been hesitant to expose those but there's been a lot of questions around custom codecs so maybe it's something that should be promoted. Maybe as helpers contributed to the driver itself. As for hiding away the bson types ... I have mixed feelings about that but I imagine it would be weird to do the other and not this. You will perhaps have noticed similarities between Morphia's Filter classes and the driver's. Morphia has its own API because the driver heavily leans in to the Bson type. So it's not without precident in Morphia. Something to consider for 3.0, perhaps.

The @CodecProvider annotation is an intriguing notion, actually. Right now i'm using SPI for some forms of plugin/discovery but that apparently doesn't play well with the module system. This might be a nice way to make such discovery automatic and not having to manually register various types. I'll open an issue against 3.0 for that one.

[zenbones]

In my opinion, the new Filter classes and filter() method were a positive change in the API. On the other had the loss of a fluent API for update operations was not so positive. I've ended up wrapping that back into a fluent API that tracks the requested updates in a list and emits an UpdateOperator[] on query execution.

From my reading of the code, I think using BsonValue in set and update operations will work correctly and has the advantage of being well-defined. I'm not always positive how a Java Object will be interpreted, but using a BsonValue I know exactly what I'm getting. It would seem a natural custom conversion point to take an arbitrary Java type and output BsonValue, and visa versa.

[evanchooly]

Agreed about the fluent API. But it had its own (implemenation) wrinkles that kept getting in the way (especially in the Query API). This approach is a much simpler implementation and is actually user extensible since anyone can create a new Filter implemention, e.g., for those times when Morphia lags behind the driver/server. It would be interesting to work an optional/experimental API to introduce something on top of that, though. Something lambda based so that the boundaries of aggregate Filters like $and and $or have clear, error-proof boundaries. I'll ponder that one, too.

If I were to add an API to paper over the Bson types it would only be for the primitive values: int, long, etc and, say, String. Any complex type otherwise should have a codec. But BsonString is weird to work with and it's not immediately obvious that a Long is a BsonInt64, e.g. It's all learnable stuff, of course, but part of Morphia's value prop is hiding some of those lower level details from developers.

[zenbones]

Good points on BsonValues. You could always adopt JsonNode from Jackson, but I see where you would want independence. But a JsonNode-like series of classes that knows how to convert itself to/from BsonValue would not be hard, and than you could accept codecs that translated to/from this canonical standard, and add an @codec or @CodecProvider to make the definition easy. I guess for 3.0, although that can all be done as pure extensions of the current APIs, so does not necessarily need a 3.0.

UpdateOperators can be improved with a simple extension as well...

public class MorphiaUpdates<T> {

  private final Query<T> query;
  private final LinkedList<UpdateOperator> updateOperatorList = new LinkedList<>();
  private final HashMap<String, Object> setOnInsertMap = new HashMap<>();

  public MorphiaUpdates (Query<T> query) {

    this.query = query;
  }

  protected UpdateOperator[] getCollected () {

    if (!setOnInsertMap.isEmpty()) {
      updateOperatorList.add(UpdateOperators.setOnInsert(setOnInsertMap));
    }

    return updateOperatorList.toArray(new UpdateOperator[0]);
  }

  public MorphiaUpdates<T> disableValidation () {

    query.disableValidation();

    return this;
  }

  public MorphiaUpdates<T> enableValidation () {

    query.enableValidation();

    return this;
  }

  public MorphiaUpdates<T> setOnInsert (String field, Object value) {

    setOnInsertMap.put(field, value);

    return this;
  }

  public MorphiaUpdates<T> set (String field, Object value) {

    updateOperatorList.add(UpdateOperators.set(field, value));

    return this;
  }

  public MorphiaUpdates<T> unset (String field) {

    updateOperatorList.add(UpdateOperators.unset(field));

    return this;
  }

  public MorphiaUpdates<T> push (String field, Object value) {

    updateOperatorList.add(UpdateOperators.push(field, value));

    return this;
  }

  public MorphiaUpdates<T> removeFirst (String field) {

    updateOperatorList.add(UpdateOperators.pop(field).removeFirst());

    return this;
  }

  public MorphiaUpdates<T> removeLast (String field) {

    updateOperatorList.add(UpdateOperators.pop(field));

    return this;
  }

  public MorphiaUpdates<T> removeAll (String field, Object value) {

    updateOperatorList.add(UpdateOperators.pullAll(field, List.of(value)));

    return this;
  }
}

...or something similar.