Implement and Update Mapping API

[bytefish]

I think we should modify the Mapping API (AbstractMapping) a bit, so it better maps to the real Database Types. Since the underlying Microsoft JDBC driver uses java.sql Types, the API methods should define those, too. I have created a Branch 2.0-api for it, so it can be done outside the master branch.

At the same time we should also raise the JDBC driver Version to the latest 7.2.2.jre8 to get the latest bugfixes into the code.

• Raise mssql-jdbc dependency to 7.2.2.jre8
• Update the API for all missing types
• Add API methods to allow mapping primitive types like char, int
• Use Java Functional Interfaces instead of homegrown Func2

The Branch is here:

• https://github.com/bytefish/JSqlServerBulkInsert/tree/2.0-api

[bytefish]

@vslee Here is what I did so far and we can discuss about everything. I am not a dictator.

Dependencies

I updated to 7.2.2.jre8.

Functional Interfaces

I removed the Func2<S, T> functional interfaces and replaced them with the standard Java Functional Interfaces, that makes sense I think.

Converters

Next on my list was the propertyGetter / wrapper stuff in the AbstractMapping, that just screams for being extracted. In the Issue #6 there was a problem inserting nulls, so I introduced an interface IConverter:

package de.bytefish.jsqlserverbulkinsert.converters;

public interface IConverter<TSourceType> {

    Object convert(TSourceType value);
}

That has a base Implementation, that returns null when the given value is null:

package de.bytefish.jsqlserverbulkinsert.converters;

public abstract class BaseConverter<TSourceType> implements IConverter<TSourceType> {

    public Object convert(TSourceType value) {
        if(value == null) {
            return null;
        }

        return internalConvert(value);
    }

    public abstract Object internalConvert(TSourceType value);
}

An example of such a Converter is for converting BigDecimal values:

package de.bytefish.jsqlserverbulkinsert.converters;

import java.math.BigDecimal;

public class BigDecimalConverter extends BaseConverter<BigDecimal> {

    private final int scale;

    public BigDecimalConverter(int scale) {
        this.scale = scale;
    }

    @Override
    public Object internalConvert(BigDecimal value) {
        return value.setScale(scale, BigDecimal.ROUND_HALF_UP);
    }
}

A method signature in the AbstractMapping still looks like the old one, but under the hood we pass the converter into it, which is just like using the wrapper function:

protected void mapInteger(String columnName, Function<TEntity, Integer> propertyGetter)
{
    mapProperty(columnName, Types.INTEGER, propertyGetter, new IntegerConverter());
}

For now I commented the mapToUtcNanoSeconds out to get it compiled quickly and show off my ideas. I did add a class TimestampUtils though, that implements the Conversion method you wrote -- nothing is lost!

Missing Functions

Tommorow I will look through what's still missing to have a more complete API. I think about UUIDs, Geometric Types, ...

[bytefish]

Primitive Types

If you are interested in adding it: Some time ago @kowalczm added support for primitive types to the PgBulkInsert project. It uses the ToIntFunction of Java. I think something similar can be done for this API (by wrapping the property getter or something similar), so it also supports primitive types:

• https://github.com/bytefish/PgBulkInsert/blob/acf2517b247ddf1e9ca7d32392ba03b877d55c84/PgBulkInsert/src/main/java/de/bytefish/pgbulkinsert/mapping/AbstractMapping.java#L85

[vslee]

Looks like great work!

[bytefish]

Thanks. I took a step to move the mapUTCNano methods into a separate class. In C# you have Extension methods to extend the API surface more modular for such functions. I know, these are methods you need in your project!

So I added a class DateTimeExtensions, which can be used like this. I am especially unhappy with the reference to this (see my Picasso drawing). It is safe to do at this moment, still it looks a little obscured:

Do you have a better idea for an "extendable" API in Java? Maybe using a Builder Pattern or something?

[vslee]

I am more of a C# dev, only using Java for a small of my project. This solution is not the prettiest, but looks like it will work.

[bytefish]

Thanks for the feedback. I will check tommorow, if all unit tests pass. It's a very bad habit of me to refactor projects, before running the unit tests. 🤫

[vslee]

All of the tests pass, btw

[bytefish]

Great! 😎

[vslee]

Also, I like that the structure of this project largely mirrors that of PgBulkInsert. Makes exchanging ideas between the two easier. One day, the two might even be able to merge.

[bytefish]

Yes, I already had written an abstraction over the two libraries some years ago. But such abstractions are always the smallest denominator of both and I think Postgres has some specialities, that will be hard to abstract away without leaking details. Think of JSONB Columns, GIS, ... What I have learned through many failed projects 🤭: Better expose all specific functionality with a clean API and leave the abstraction part to the project requirements. 🙂

[bytefish]

The changes will be released with 2.0.