Code Monkey home page Code Monkey logo

bson-codecs-jsr310's Introduction

BSON codecs for Java 8 Date and Time API (JSR-310)

Build Status Maven Central Javadocs

The library provides codecs for the following JSR-310 classes:

  • java.time.DayOfWeek
  • java.time.Duration
  • java.time.Instant
  • java.time.LocalDate
  • java.time.LocalDateTime
  • java.time.LocalTime
  • java.time.Month
  • java.time.MonthDay
  • java.time.OffsetDateTime
  • java.time.OffsetTime
  • java.time.Period
  • java.time.Year
  • java.time.YearMonth
  • java.time.ZonedDateTime
  • java.time.ZoneId
  • java.time.ZoneOffset

Usage

In order to utilize the codecs one can use CodecRegistries helper, for example in case of Mongo synchronous client:

MongoClient mongoClient = MongoClients.create();
CodecRegistry codecRegistry = CodecRegistries.fromRegistries(
        MongoClientSettings.getDefaultCodecRegistry(),
        CodecRegistries.fromCodecs(new DurationAsDecimal128Codec())
);
MongoDatabase database = client
        .getDatabase(...)
        .withCodecRegistry(codecRegistry);

Note that depending on a context a different set of codecs might be necessary. There are three main factors to consider when choosing codecs:

  • queryability - how much stored values are capable of being searched;
  • sortability - how much stored values are capable of being ordered;
  • readability - how much stored values are readable for human.

The table below presents the recommendations for all the factors. The more + signs a cell contains the better a row codec is in terms of a column factor:

Codec Queryability Sortability Readability
DayOfWeekAsInt32Codec ++ ++ +
DayOfWeekAsStringCodec + ++
DurationAsDecimal128Codec + ++
DurationAsDocumentCodec ++ + +
DurationAsStringCodec ++
InstantAsDateTimeCodec + ++ +
InstantAsDocumentCodec ++ + +
InstantAsStringCodec ++
LocalDateAsDateTimeCodec + ++ +
LocalDateAsDocumentCodec ++ + +
LocalDateAsStringCodec ++
LocalDateTimeAsDateTimeCodec + ++ +
LocalDateTimeAsDocumentCodec ++ + +
LocalDateTimeAsStringCodec ++
LocalTimeAsDateTimeCodec + ++ +
LocalTimeAsDocumentCodec ++ + +
LocalTimeAsInt64Codec ++ ++
LocalTimeAsStringCodec ++
MonthAsInt32Codec ++ ++ +
MonthAsStringCodec + ++
MonthDayAsDecimal128Codec + ++ ++
MonthDayAsDocumentCodec ++ + +
MonthDayAsStringCodec ++
OffsetDateTimeAsDocumentCodec ++ + +
OffsetDateTimeAsStringCodec ++
OffsetTimeAsDocumentCodec ++ + +
OffsetTimeAsStringCodec ++
PeriodAsDocumentCodec + +
PeriodAsStringCodec ++
YearAsInt32Codec ++ ++ ++
YearMonthAsDecimal128Codec + ++ ++
YearMonthAsDocumentCodec ++ + +
YearMonthAsStringCodec ++
ZonedDateTimeAsDocumentCodec ++ + +
ZonedDateTimeAsStringCodec ++
ZoneIdAsStringCodec + ++
ZoneOffsetAsInt32Codec ++ ++
ZoneOffsetAsStringCodec + ++

bson-codecs-jsr310's People

Contributors

cbartosiak avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar

bson-codecs-jsr310's Issues

Make codecs configurable to support different BSON types

Codecs should be configurable to allow for conversions to and from different BSON types:

  • DurationString, Object, Decimal128;
  • InstantString, Object, Date;
  • LocalDateString, Object, Date;
  • LocalDateTimeString, Object, Date;
  • LocalTimeString, Object, Date, 64-bit integer (a number of nanoseconds since midnight);
  • MonthDayString, Object, Decimal128;
  • OffsetDateTimeString, Object;
  • OffsetTimeString, Object;
  • PeriodString, Object;
  • YearMonthString, Object, Decimal128;
  • ZoneOffsetString, 32-bit integer;
  • ZonedDateTimeString, Object;

This will allow for supporting different use cases dependent on a given context, e.g. one would like to sacrifice sortability in exchange for queryability.

OffsetDateTime & ZonedDateTime: the dateTime field should CONVERT to UTC, and not store LocalDate with a "Z" appended

Hello,

First, thanks for this wonderful library!

I'd like to configure its data-representations to be as close as possible as the original processing done by MongoBD, and as compact as possible.

Here is my configuration:

@Singleton
public class Jsr310AdditionalCodecsProvider implements CodecProvider {
    // As date objects to be able to compare them and have an ISO and smaller representation
    private static final LocalDateTimeCodec LOCAL_DATE_TIME_CODEC = new LocalDateTimeCodec();

    // As strings to have an ISO and smaller representation
    private static final ZoneOffsetAsStringCodec ZONE_OFFSET_CODEC = new ZoneOffsetAsStringCodec();

    // As strings to have a smaller representation
    private static final ZoneIdAsStringCodec ZONE_ID_CODEC = new ZoneIdAsStringCodec();

    @Override
    public <T> Codec<T> get(Class<T> clazz, CodecRegistry registry) {
        if (clazz.equals(ZonedDateTime.class)) {
            return (Codec<T>) new ZonedDateTimeAsDocumentCodec(LOCAL_DATE_TIME_CODEC, ZONE_OFFSET_CODEC, ZONE_ID_CODEC);
        } else if (clazz.equals(OffsetDateTime.class)) {
            return (Codec<T>) new OffsetDateTimeAsDocumentCodec(LOCAL_DATE_TIME_CODEC, ZONE_OFFSET_CODEC);
        } else if (clazz.equals(ZoneOffset.class)) {
            return (Codec<T>) ZONE_OFFSET_CODEC;
        } else if (clazz.equals(ZoneId.class)) {
            return (Codec<T>) ZONE_ID_CODEC;
        }
        return null; // Other default codecs are fine to us
    }
}

The goal is to store OffsetDateTime & ZonedDateTime as close as possible as the default MongoDB codecs: as $date fields to be able to compare them, with just one or two additional fields to be able to restore the original offset, lost with the default MongoDB converter, as well as the original zone, non-standard, and thus also lost.

Unfortunately, the dateTime fields are stored as LocalDate with a "Z" appended, making the date objects not comparable.

Example of stored document: the two OffsetDateTimes are at the same moment, created on my machine that is currently GMT+1 (will be GMT+2 in 6 months when DST kicks in):

{
  "offsetDateTime": {
    "dateTime": { "$date": "2022-03-02T15:15:44.555Z" },
    "offset": "+01:00"
  },
  "offsetDateTime2": {
    "dateTime": { "$date": "2022-03-02T16:15:44.555Z" },
    "offset": "+02:00"
  }
}

So, as long as you create documents on the same machine, or on machines with the same offset AND that do not honor Daylight Saving Time, then the created dates are comparable.

That's a lot of ifs :)

And semantically speaking, if we store a "Z"-date in database, we expect it to be UTC, like MongoDB does by default.

We would also expect Instant.parse(offsetDateTime2.dateTime).atOffset(ZoneOffset.of(offsetDateTime2.zone)) to restore the original OffsetDateTime: it currently does not.

I'd like both fields above to have theirs dateTime to "$date": "2022-03-02T14:15:44.555Z".

Did I use the library wrong? Is there a possible way to do this?

If not, is it possible to create alternate ZonedDateTimeAsDocumentCodec & OffsetDateTimeAsDocumentCodec classes that do not use a LocalDateTimeCodec or that convert them to UTC first?

Thanks a lot.

Support ZoneId, DayOfWeek and Month

Implement codecs for the following types:

  • ZoneId - convertible to and from String;
  • DayOfWeek - convertible to and from String and 32-bit integer;
  • Month - convertible to and from String and 32-bit integer;

Note that #1 has to be done first.

Wrap unchecked exceptions

CodecConfigurationException, BSONException or its subtypes should be the only unchecked exceptions thrown by the codecs.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.