agcom / bson Goto Github PK

Move group id to com.github.agcom.bson.

Require changes at:

• build.gradle group property.
• Readme
• JCenter published packages.
• Release notes hint for earlier releases.
• artifactId of mongodb and serialization.

Referring to org.mongodb.bson documentations,

• A CodecRegistry.get(class) should throw CodecConfigurationException if it can't find any codec.
• A CodecProvider.get(class, registry) should return null if it can't provide a codec.

This is not the case with the current implementation. It always returns a SerializationCodec, because, the serializer extraction procedure always returns a serializer.

The above policies must be obeyed.

E.g. in case of composing codec registries using helper functions from CodecRegistries, the SerializationCodecRegistry never fails, so, other registries under the SerializationCodecRegistry will never get place.

The serializer extraction procedure is all healthy, until the last step. There is no way to determine if a context contains a polymorphic serializer for a requested class, without an object of that class, which is not available at the moment (in a CodecRegistry).

Then, if there is no polymorphic serializer registered in the context, a SerializationException will be thrown.

Related to #26.

It's iterating over the whole context every time a polymorphic serializer is needed.

this can be enhanced by caching using a map (sub classes (including the base class) to base class).

Like json { ... }.

It's pretty useful in MongoDB Java driver, especially building complex queries.

It's currently 11, drop to 1.6 as the Kotlinx serialization library does.

Dropping to 1.8 (the minimum possible).

• Move main module into a sub-module called core
• Code documentations.
• Change internal package structure
• Clean and group the tests + extend the tests
• Move maven artifact pom configuration, to a file pom.xml.
• Serializers serialName:
  Custom serializers should provide a unique serial name that identify both the serializable class and the serializer itself, ignoring type arguments, if they are present.
• Default bson context tests (that it won't break)
• TemporalSerializer tests (so there is no code typo on porting to each others)
• Create unexpected bson type universal exception
• Special serializers tests

In a sub module, released in a separate package.

bson-core will belong to Kotlin implementation of the new bson model (#27).

Use BSON instead of Bson or bson where ever it's referring to the BSON format.

• Quick start (Setup, Usage)
• Code documentations
• Maven artifact importing
• CHANGELOG

Take a look at org.bson.BSON class for regex flags transformations. It may be deprecated.

The mistake I did was starting from 1.0.0.

• 1.0.0 --> 0.1.0
• 1.0.1 --> 0.2.0
• 1.1.0 --> 0.3.0
• 1.1.1 --> 0.4.0
• 1.2.0 --> 0.5.0
• 2.0.0 --> 1.0.0

Publish Maven package on Jcenter (Bintray).

• core module
• codec module

Like JsonStreamingInput / JsonStreamingOutput

Here we work with bytes wrapped by IO classes.

The decodeBson and encodeBson functions use the BsonValueSerializer to port the BsonValue into platform types, then wrap and save as a BsonValue. That's hip-hop, eliminate it.

The goal is to let the user put any serializable object into the Document and we take care of serializing it.

So, an instance of SerializationCodecRegistry is needed to pass into DocumentCodec.

Especially for dump and load functions

Transforming value into byte array, then rolling back using the same serializer.

For serialization module.

This is easily possible after #27 (Self bson model in Kotlin).

Currently, the library is using models from the org.mongodb.bson. It's all fun and game until you need the flexibility.

The library design is source of most boiler plate codes. I would like to create a Kotlin implementation of bson model, based on Json model in Kotlinx serialization and inspired by org.mongodb.bson.

Examples of not enough flexibility (they are just source of boiler plate codes),

• BsonPrimitive subclass of BsonValue is not defined.
• BsonType is redundant when class type is self explanatory.
• BsonArray can extend BsonDocument

• bson-core:1.0.0
• bson-codec:1.0.0

CodecRegistry documentation says If a class is registered under multiple polymorphic serializers, the chosen serializer is unpredictable.

There are clean workaround for this and are well known.

The workarounds include using the SerializationCodec` class.

However, the unpredictable behavior can be removed.

The idea is to declare an SerialInfo annotation and if multiple bases are present for a sub, then the base annotated with the declared annotation will take precedence.

Can call the annotation DefaultBase or something like that.

Porting Json models to Bson

• Transform BsonValue to anything
• Corresponding tests

Enable this.

Implementing load function needs inferring bson type.

It's not possible to infer bson type in case of UnionKind.CONTEXTUAL and PolymorphicKind (not AbstractPolymorphicSerializer).

So, adding another load function which additionally accept a BsonType, which is used as the bytes inferred bson type. The original function throws if it can't infer the bson type.

Yet the problem exists in case of more complex serializers which is normal (there is no flag present).

This is not true in Json, you work with strings there and { flags for a Json object. Other than that, literal value is extracted.

If there be a way to determine if a byte array contains a bson document, the problem is solved.

Originally posted by @agcom in #6 (comment)

• org.bson.Document --> BsonDocument #57
• org.bson.types.Code --> BsonJavaScript

Also some platform types,

• ByteArray --> BsonBinary
• UUID --> BsonBinary with UUID sub type.
• Date --> BsonDateTime

It's not part of bson specification, Valid BSON data is represented by the document non-terminal.

Well, I wish it would support the primitives but it's not that simple (it's possible but adds cognitive load and is error prone).

Support for Kotlin version 1.4.0 and Kotlinx serialization version 1.0.0-RC.

Almost all of the dependencies should be declared as transitive (api).

They're currently non-transitive and makes the library unusable.

They're defined as object extension, which makes them unusable.

Should be extension to the corresponding class companion object or a function with the corresponding class name.

• BsonBinary
• BsonRegularExpression

Setup Actions,

• A test job, triggered on any push to any branch
• A build-artifact and publish-bintray to publish Jar package (as Maven artifact); Triggered on tag creation.

Non-static byte arrays are used as expected values for dump function tests.

Although they use stable and tested API s to generate the byte arrays, yet it's not a good practice.

Connect Bintray to Sonatype and enable maven central sync .

Related to #60.

Obsolete packages:

• bson-core:1.0.0
• bson-codec:1.0.0
• bson-serialization:1.0.1
• bson-mongodb:1.0.1

UUID serializes into a BsonBinary sub type.

I believe, it's completely safe to set that function to true, for non-streaming input / output s.

E.g. UNDEFINED, DB_POINTER, SYMBOL, TIMESTAMP, JAVASCRIPT_WITH_SCOPE, ...

Full list:

• BsonDbPointer
• BsonJavaScriptWithScope
• BsonMaxKey
• BsonMinKey
• BsonSymbol
• BsonUndefined
• BsonTimeStamp

In the current implementation, there is a lot of potentials for org.bson.BSONException to be thrown.

The end user will only expect kotlinx.serialization.SerializationException, especially com.github.agcom.bson.BsonException.

So, remove that potentials and replace them with the project exclusive exception, com.github.agcom.bson.BsonException.

Currently, primitive types use a common serializer called BsonValueSerializer.

This is necessary according to Kotlinx serialization specification on serializers.

It should use streaming input / output, but to be agile, implement it using BsonValue as intermediate type.

It works, but can be enhanced (speed and memory) after #5.