jdbi is designed to provide convenient tabular data access in Java; including templated SQL, parameterized and strongly typed queries, and Streams integration

Related tags

Database jdbi
Overview

Jdbi Logo

Build Status

The Jdbi library provides convenient, idiomatic access to relational databases in Java.

Jdbi is built on top of JDBC. If your database has a JDBC driver, you can use Jdbi with it.

Prerequisites

Jdbi 3 requires Java 8 or better.

We run CI tests against Java 8, 11, 14, and 15. We recommend running the latest GA JDK.

At this point Java 8 is considered deprecated. While Jdbi does not (yet) have a specific date to drop support, please chart your path forward to a supported JDK!

Builds

Jdbi is built with Maven:

$ mvn clean install

The tests use real Postgres and H2 databases.

You do not need to install anything--the tests will spin up temporary database servers as needed.

Contributing

Please read CONTRIBUTING.md for instructions to set up your development environment to build Jdbi.

Versioning

We use SemVer for versioning.

License

This project is licensed under the Apache 2.0 license.

Project Members

  • Brian McCallister (@brianm) - Project Founder
  • Steven Schlansker (@stevenschlansker)
  • Henning Schmiedehausen (@hgschmie)
  • Matthew Hall (@qualidafial)
  • Artem Prigoda (@arteam)
  • Marnick L'Eau (@TheRealMarnes)

Special Thanks

  • Alex Harin (@aharin) - Kotlin plugins.
  • Ali Shakiba (@shakiba) - JPA plugin
  • @alwins0n - Vavr plugin.
  • Fred Deschenes (@FredDeschenes) - Kotlin unchecked extensions for Jdbi functions. @BindFields, @BindMethods annotations.
Comments
  • For JDBI 3 to support Kotlin, need plugin points...

    For JDBI 3 to support Kotlin, need plugin points...

    Kotlin has a lot of type information available at runtime, so if we can write a Kotlin plugin for JDBI we can take advantage of that information.

    I'll write the plugin, if you add extension points.

    Things in Kotlin, related to JDBI:

    • like Java 8, we have parameter names, but in a different way. So if the non annotated parameters can have a specific object mapper instead of just DefaultObjectMapper, we can use ours instead. We can detect a Kotlin class and apply logic, otherwise fallback to the other DefaultObjectMapper.
    • we know if a property or parameter is nullable or not, so we can do error checking on required vs. optional parameters.
    • for data classes, all properties are also in the constructor, and normally we do not have a default constructor, so we can use the names of incoming parameters (i.e. fields in the query results) to pick the constructor.
    • we have copy constructors in data classes so anywhere we want to clone or make a slight modification to a immutable class we can copy it while changing the set list of fields.
    • we have optional parameters, and can detect when they exist, and can call using or omitting them (call by name)
    • for normal classes we can also look at the list of constructors and parameter names and try to make a best fit
    • we can reify generic parameters for inline functions so some methods can be simplified, we can do this as an extension function to add variations of API that do not need the class passed in as parameters (i.e. DBI.open(SomeClass) could infer SomeClass from the left side of the assignment). I think our function parameter types also have full generic information in the metadata when viewed through reflection, same for return type. I'll have to check that one, I think reflection can read it, but isn't reified.
    • we have default methods for interfaces, but not sure they are done the same as Java 8 ones (they copy into the first level of the class hierarchy that implements the interface I think, not sure they exist in the interface bytecode itself)
    • we have lambdas, function classes, etc. and can treat a parameter that is an interface with a single method as a lambda as well (automatic conversion).

    So given that, we should be able to help with SqlObject building to help decide binding by parameter name, and if things are optional coming in. For results (I think we can do this already without changes) we can bind the results to classes or class hierarchies given that we can see names nicely, pick constructors besides the default, take advantage of knowing about default values (for non nullable things), which parameters are really required, etc.

    Where else can we fit in? and maybe a first early step is the SqlObject change for the default binder. And then a result set binder, and a way to make it the default (I seem to remember it could be set per class as an annotation, but here we would want one general default to apply). Other places we can extend?

    feature 
    opened by apatrida 48
  • Use registered mapper factories to support value-typed properties in BeanMapper

    Use registered mapper factories to support value-typed properties in BeanMapper

    We use value objects extensively in our beans. Example:

    class Employee {
      EmployeeId id;
      LocalDate hiredOn; // new in Java 8
      Money wage;
      ...
    }
    

    We have mappers registered for these value types (e.g. EmployeeIdMapper), and it would be great if registering a mapper (perhaps restricted to subclasses of TypedMapper) would allow BeanMapper to resolve the column into the value object.

    Since most (all?) value type mappers just map the first column, I figure I could whip up a facade over the ResultSet that only exposes a single column index/name in the underlying ResultSet, and send that to the mapper for the column.

    What I haven't figured out is how to get at the MappingRegistry from inside BeanMapper to resolve a mapper for a value-typed column.

    If you could point me in the right direction, I'd be happy to do the work, and submit a pull request.

    opened by qualidafial 43
  • add basic Immutables integration

    add basic Immutables integration

    this PR attempts to add initial Immutables integration. it only recognizes the default name styling and method arguments / return types for now.

    This also breaks out some of the core BeanMapper reflection logic into a new PojoProperties interface, which intends to allow pluggable bean-like conventions. It's explicitly still internal, though.

    feature improvement 
    opened by stevenschlansker 36
  • Poor DAO performance in jdbi3

    Poor DAO performance in jdbi3

    Because I spotted the degraded performance of SqlObject (DAO) calls between jdbi2 and jdbi3, I did some quick and simple comparison tests.

    The test code itself is very simple - it is just two database operations in the loop. The first operation inserts the record into the database, second operation just reads it using the primary key.

    Test conditions

    • jdbi3 - v3.13.0
    • jdbi2 - v2.78
    • database: local Postgresql 11.7
    • JDBC driver - postgresql:42.2.12

    Results

    1. Execution time in milliseconds, num is a number of iterations.
      num     3-DAO    2-DAO    3-API    2-API
       10       480      165      167      159
      100     3 769      690      690      643
     1000    31 259    4 771    4 800    4 889
    10000   291 862   39 221   40 308   42 069
    
    1. Iteration average execution time in milliseconds.
      num   3-DAO   2-DAO   3-API   2-API
       10   48.00   16.50   16.70   15.90
      100   37.69    6.90    6.90    6.43
     1000   31.25    4.77    4.80    4.88
    10000   29.18    3.92    4.03    4.20
    

    Conclusions/Comments

    • The difference between "3-DAO" column and the others is obvious and significant. I'm conscious of switch from cglib to dynamic proxies between jdbi2 and jdbi3 (#341, #456), but that level of degradation is really worrying.
    • I didn't notice any other symptoms that could justify such difference - no connection leakage, no increasing memory consumption.

    Any ideas what could be wrong? Maybe some other cglib alternative could be considered/verified (e.g Byte Buddy)?

    improvement 
    opened by gtaborcrossword 33
  • Allow instantiation of ParsedSql and ParsedParameters

    Allow instantiation of ParsedSql and ParsedParameters

    Hello @jdbi Team :)

    This change changes ParsedSql constructor visibility from private to protected.

    Why did I change this? Let me briefly describe.

    We recently migrated from JDBI v2 to v3 and we are really astonished of the number of enhancements, but while migrating the code I encountered small blocker.

    In our solution I use SqlParser to process SQL queries from annotated SQL objects. This processing consist of some cheap operations (e.g. prepend DAO name at the query beginning) and some pretty expensive operations (i.e. parse whole SQL and rewrite schemas found in query). Due to expensive nature of SQL parsing resultant SQL should be cached.

    What I would like to do is to cache intermediate SQL together with named parameters, e.g. have cache like this one:

    intermediateSql = "select a, b, c from {SCHEMA}.test where a > :a", parameters = [ a ]
    intermediateSql = "insert into {SCHEMA}.test (a) values (:a)", parameters = [ a ]
    

    And have custom implementation of ParsedSql which can be created by:

    public class MyParser implements SqlParser {
      public ParsedSql parse(String sql, StatementContext ctx) {
        Item item = cache.computeIfAbsent(sql, s -> doExpensiveSqlParsing(s, ctx));
        String intermediateSql = item.intermediateSql;
        ParsedParameters parameters = item.parameters;
        String finalSql = replaceAll("{SCHEMA}", schema);
        return new ParsedSql(finalSql, parameters);
      }
    

    Since constructor is private and because ParsedSql can be created only via ParsedSql.Builder which takes SQL in parts, the ParsedSql instance cannot be instantiated from fully rendered SQL and known parameters. I have to split it into parts and merge using parameters one-by-one. This is problematic because it makes ? a magic string which cannot be used in queries (because it's used to split it).

    With current solution I can only accept ? being magic or cache ParsedSql objects per schema which cause the number of items in cache to raise because there is no limit for a number of applications (and thus the number of schemas located on DB server, due to multitenant environment where application databases are isolated from each other). This will cause cache to grow bigger together with a number of applications, e.g.:

    select a, b, c from app0001.test where a > :a; names = [ a ]
    select a, b, c from app0002.test where a > :a; names = [ a ]
    select a, b, c from app0003.test where a > :a; names = [ a ]
    select a, b, c from app0004.test where a > :a; names = [ a ]
    insert into app0001.test (a, b, c) values (:a, :b, :c); names = [a, b, c]
    insert into app0002.test (a, b, c) values (:a, :b, :c); names = [a, b, c]
    insert into app0003.test (a, b, c) values (:a, :b, :c); names = [a, b, c]
    insert into app0004.test (a, b, c) values (:a, :b, :c); names = [a, b, c]
    etc...
    

    Please let me know if this change (private to protected) is acceptable. The other option for me would be to have Builder more fluent so I can set both SQL and parameters at once, not in parts, e.g.:

    ParsedSql sql = ParsedSql.builder()
      .setSql(finalSql)
      .setParameters(parameterNames)
      .build();
    
    feature 
    opened by sarxos 30
  • Add lambda-friendly callback interfaces

    Add lambda-friendly callback interfaces

    Using JDBI with Java 8 lambdas is great until you want a callback that doesn't return a value. You can't cast the lambda to VoidHandleCallback because lambdas can only be cast to interfaces. It's an annoyance, not an obstacle, but one that's bugged me often enough that I want a better experience, and it's pretty easy to add.

    This change adds functional interfaces that Java 8 can infer when the lambda does not return. It does not add any Java 8 dependencies.

    Objections?

    opened by christophercurrie 30
  • Use java.lang.reflect.Type instead of Class<?> in factories

    Use java.lang.reflect.Type instead of Class in factories

    To do

    • [x] Move ArgumentFactory to TypeToken
    • [x] Ditto ResultColumnMapperFactory
    • [x] Ditto ResultSetMapperFactory
    • [x] Ditto CollectorFactory
      • [x] Change ResultBearing.collectInto(Class) to TypeToken?
    • [x] Keep all the method that take Class, and add a sister method that accepts TypeToken
      • [x] SQLStatement.dynamicBind
    • [x] Expose argument factory registry (Foreman) through statement context.
    • [x] Enhance existing BinderFactory implementations to take advanced of generic type information.
    • [x] Implement OptionalArgument
    • [x] Confirm ResultReturnThing is getting full generic type information
    • [x] Use Classmate GenericType instead of Guava TypeToken

    Questions

    • See #258 ~~Change SQLObject from Class to TypeToken? Implies inspecting a possibly generified DAO class and producing methods depending on the nested parameters in the type token.~~
    • ~~Built in row mappers use TypeToken instead of Class? Implies inspecting a possibly generified bean class and projecting that type onto generic members.~~

    Unrelated todos discovered while working on this--not until after this PR

    • See #259 ~~Rename registry methods xyzFor to findXyzFor and return an Optional~~
    • See #259 ~~StatementContext.columnMapperFor renamed to findColumnMapperFor, returns Optional~~
    • See #259 ~~Collapse factory accepts and build methods into a single provide (or otherwise named) method that returns an Optional.~~
    • See #259 ~~Remove generic type parameter from ArgumentFactory?~~
    • [x] ~~Remove generic type parameter from CollectorFactory?~~
    • [x] ~~Remove ResultBearing.collectInto(Class)--it's broken~~
      • ~~We could possibly do collectInto(TypeToken), but CollectorFactory would have to be verify the element type agrees with the collector result type.~~
    • [x] ~~BuiltInArgumentFactory enum encoding should use Enum::name~~
    • See #259 ~~Rename built in column mappers to exclude Column from name--it's redundant~~
    • See #263 ~~Do we need all those SQLStatement.bind(int|String, SpecificType) methods? Seems like a design smell to have these for every built in type, but users are on their own for custom types?~~
    • See #263 ~~Eradicate foo != null ? foo.something() : somethingElse~~
    • See #263 ~~Likewise for if (!x) { foo(); } else { bar(); }~~
    • See #263 ~~dynamicBind should just overload bind and put the argument type last, effectively as an optional parameter~~
    • See #263 ~~Should we get rid of ObjectArgument? SQLStatement.bind(int|String, Object)? Or maybe require users to call overloaded method with type parameter if the argument might be null~~
      • ~~If so, should also get rid of Foreman.waffle fallback to argument of type Object. An argument factory should be provided.~~
    • See #263 ~~SqlObjectBuilderBridge: Should this be a ServiceLoader SPI instead of using reflection?~~
    • See #263 ~~SqlStatementCustomizingAnnotation should be annotated @Target(ElementType.ANNOTATION_TYPE)~~
    • See #263 ~~@MapResultAsBean is equivalent to @RegisterMapperFactory(BeanMapperFactory.class). Do we need both?~~
    • See #263 ~~@Mapper should be a SqlStatementCustomizingAnnotation instead of magic.~~
    • ~~Should EnumColumnMapper be exploded into EnumByNameColumnMapper and EnumByOrdinalColumnMapper?~~ No, the factories are sufficient for declarative usage
    • ~~parameter vs paramater~~
    • See #263 ~~Binder.bind needs a resolved parameter type argument to address #242~~
    opened by qualidafial 29
  • Migrate SqlObject from CGLIB to Java Proxy implementation.

    Migrate SqlObject from CGLIB to Java Proxy implementation.

    Submitted for discussion with the team.

    This PR removes CGLIB and ASM from the project. It also restricts SqlObject extensions to public interfaces only.

    This was surprisingly straightforward. Only drawback I saw was that extending Cloneable in a SqlObject class stopped working, which forced me to change some tests--pretty sure we don't want our users using clone() in their SQL Objects any way.

    opened by qualidafial 28
  • Decrease ClasspathStatementLocator GC pressure.

    Decrease ClasspathStatementLocator GC pressure.

    Hi!

    ClasspathStatementLocator gives essential GC pressure due to many string concatenation for every query even if static SQL objects are used.

    cache_key = '/' + mungify(ctx.getSqlObjectType().getName() + '.' + name) + ".sql";
    

    I propose to use Method object as cache key, this is completely enough for SQL objects.

    And also I propose to cache individual SQL statements for SQL object methods cause they are static.

    improvement 
    opened by john9x 28
  • Query interception support

    Query interception support

    PS: This is a copied and pasted text from an earlier discussion about supporting query interception at the #134 issue

    Hi guys, I would like to suggest a different approach at this discussion and I'd like to hear your honest feedback about it...

    I was reading this topic before came here. And, I agree with you guys that support cache layers are totally application dependent. But, I would like to set a point here: support cache layers would be hard to maintain in the long term, but allow developers to cache its queries isn't that hard.

    Let's imagine that, instead of providing a cache abstraction, JDBI could provide a way to "intercept" queries. Bellow is my suggestion:

    // Here an interface that could be provided by JDBI core module.
    public interface QueryInterceptor {
      // ExecutableMethod could be a wrapper to the java.lang.reflect.Method and the DAO implementation
      // Another approach to this method would be store the arguments and the query into the ExecutableMethod too...
      Object interceptQuery( ExecutableMethod daoMethod, String query, Object[] args );
    }
    
    // at some place on your code, you can attach the query interceptor into the Handler
    handler.attachQueryInterceptor( new MyQueryInterceptor() );
    
    // Here a valid implementation that does nothing but call the query
    public class MyQueryInterceptor {
    
      public Object interceptQuery( ExecutableMethod daoMethod, String query, Object[] args ) {
        return daoMethod.invoke( args );
      }
    }
    
    // Developers whom intend to cache their queries could create their own algorithm
    // Bellow a non-thread-safe sample code just to make my point
    public class CachedQueries {
    
      final Map<CacheEntry, List<Object> cachedData = new HashMap<>();
    
      public Object interceptQuery( ExecutableMethod daoMethod, String query, Object[] args ) {
        final CacheEntry entry = new CacheEntry( query, args );
    
        Object resultObject = cachedData.get( entry );
        if ( resultObject == null ) {
          resultObject = daoMethod.invoke( args );
          cachedData.put( entry, resultObject );
        }
    
        return resultObject;
      }
    }
    
    // represents a cached entry
    class CacheEntry {
      final String query;
      final Object[] args;
    
      // Implement here a constructor
      // Implement here a valid equals and hashCode methods
    }
    

    Of course, there is a huge room for improvement on my suggested design, but I just want to make a point: is it simple enough to be included on JDBI?

    Regards

    feature 
    opened by miere 27
  • WIP draft of JdbiTemplate based plugin

    WIP draft of JdbiTemplate based plugin

    This PR addresses #983 but also #987

    The idea is to follow springs conventions as closely as possible and expose a narrow interface that, similar to springs JdbcOperations, solely relies on the framework for transaction management.

    If this draft is approved I will add tests and better documentation.

    Also it can be considered to make JdbiUtil non-public.

    Furthermore I was thinking of supporting spring boot which uses a lot more classpath magic to even avoid writing java config

    feature on hold 
    opened by alwins0n 24
  • fix(generator): return latest supported SourceVersion instead of 8

    fix(generator): return latest supported SourceVersion instead of 8

    Fixes #2127.

    We should be able to output generated code for any supported releases >= 8. Considering the bytecode we output for the artifact (i.e. the processor, not the generated code) is always Java 8 or newer as of writing, this will not be an issue.

    We return the latest supported version for javac instead of the lowest version we expect to support, because javac will print warnings in that case. This breaks -Werror builds on versions higher than this is made to support (i.e. Java 9+ as of writing).

    Legal note: this code is submitted under the applicable licence(s) (Apache 2.0, Jan 2004) with the ownership retained as Spotify AB.

    feature improvement 
    opened by Proximyst 2
  • Generator: supported source version is lower than compiler release

    Generator: supported source version is lower than compiler release

    The current generator impl declares the supported source version as lower than the compiler's latest supported release version:

    https://github.com/jdbi/jdbi/blob/36a7882b2199e929c8eec92710ed881a23299935/generator/src/main/java/org/jdbi/v3/generator/GenerateSqlObjectProcessor.java#L56

    The compiler currently warns about this if you use the annotation processor:

    [INFO] -------------------------------------------------------------
    [WARNING] COMPILATION WARNING : 
    [INFO] -------------------------------------------------------------
    [WARNING] Supported source version 'RELEASE_8' from annotation processor 'org.jdbi.v3.generator.GenerateSqlObjectProcessor' less than -source '17'
    

    ... which will cause build failures if the user also has -Werror specified and uses Java 9 or newer.

    This should ideally return SourceVersion#latestSupported.


    I've submitted a PR to solve this issue: https://github.com/jdbi/jdbi/pull/2128

    opened by Proximyst 0
  • Factor lombok code into its own module

    Factor lombok code into its own module

    It seems that using lombok crashes the compiler in some IDEs. Factor the lombok code into a separate module so that core still compiles in such IDEs.

    The lombok module is tests-only, so it does not ship any artifacts.

    opened by hgschmie 2
  • Remove Closeable from BaseStatement

    Remove Closeable from BaseStatement

    Interestingly enough, there are only very few changes required to make BaseStatement not implement Closable. And the places are few and all internal.

    As we have never actually published that the various SqlStatement things are closable (and basically no one ever should have to deal with them directly anyway), it should be possible to make this change without causing too much scare amongst JDBI users. Or not?

    Discussion wanted!

    @hjohn would that change help your evaluation? I can follow your arguments and I am not actually sure why BaseStatement extends Closable. I don't think it is really needed. :-)

    opened by hgschmie 4
  • Evaluating JDBI. Why use `Closeable` on objects that are returned to the user that are not supposed to be closed?

    Evaluating JDBI. Why use `Closeable` on objects that are returned to the user that are not supposed to be closed?

    So, after just 30 minutes of evaluating JDBI, I ran into this issue that I think will deter me from using it.

    I want to do the following:

    jdbi.useTransaction(handle -> {
        handle.createUpdate("INSERT INTO xyz (data) VALUES (:data)")
            .bind("data", data)
            .execute();
    });
    

    Now, createUpdate returns a Closeable. My question is, why would it do this when there is no need to create the actual closeable resource until one of execute or one is called? You are basically giving me a simple "binder" type object that allows me to bind things to a simple String, but it seems this object that is returned is already an "expensive" resource (perhaps there is even an actual prepared statement created already) that will require closing. Why not defer creating the prepared statement until it is actually required?

    Now the user is getting a warning on createUpdate that this resource needs closing, and IMHO these warnings should not be ignored without good reason. Note that in this scenario, the user never needs to close anything, so why return something that is Closeable in the first place?

    I would expect the implementation of createUpdate to be something like:

      class Handle {
           UpdateBinder createUpdate(String sql) {
                return new Binder(this, sql);  // this = Handle     
           }
      }
    
      class UpdateBinder {  // not Closeable, why would it be?
           UpdateBinder (Handle handle, String sql) {
                ...
           }
    
           ... bind methods ...
    
           int execute() {
                // - use handle to create prepared statement -- use try with resources on that
                // - bind everything
                // - execute
                // - close
           }
      }
    

    No Closeable is ever returned to the user.

    improvement question investigation needed 
    opened by hjohn 7
  • Postgres partial jsonb update

    Postgres partial jsonb update

    Hi,

    I checked the documentation and didn't find anything that could help me.

    -- create
    CREATE TABLE my_table (
      id varchar(36),
      progress jsonb,
     some_prop varchar(36),
      row_version int
    );
    
    -- insert
    INSERT INTO my_table VALUES ('id1', to_jsonb('{"progressId1": {"prop1": 910, "prop2": [{"sub1": "valu", "sub2": "valu"}], "prop3": "smth"}}'::json), 1);
    
    -- fetch 
    SELECT * FROM my_table;
    
    update my_table set row_version = row_version + 1, progress=jsonb_set(jsonb_set(progress, '{progressId1,prop1}','911'), '{progressId1,prop2}', to_jsonb('[{"sub1": "valuNew", "sub2": "valuNew"}]'::json)) where id='id1';
    
    SELECT * FROM my_table;
    

    I want to perform a partial update for a bit complicated object. Let's assume that my_table contains with type LongEntity and I try to perform partial update with ShortEntity. To simplify debugging process I do it for each property:

    @SqlUpdate("update my_table set row_version = row_version + 1, progress=jsonb_set(jsonb_set(progress, '{:someProp,prop1}',:prop1::text), '{:someProp,prop2}',to_jsonb(:prop2::json)) where id=:id")
    boolean updatePartial(@Bind("id") String id, @Bind("someProp") String someProp, @Bind("prop1") long prop1, @Bind("prop2")String prop2);
    

    The biggest difficulties I have with {:someProp,prop1} and {:someProp,prop2} (aka dynamic keys to update json). I got the exception: org.jdbi.v3.core.statement.UnableToExecuteStatementException: org.postgresql.util.PSQLException: ERROR: function jsonb_set(jsonb, unknown, text) does not exist Hint: No function matches the given name and argument types. You might need to add explicit type casts.

    Does Jdbi support such syntax at all? Thanks for any comments in advance

    investigation needed 
    opened by TanyRay 1
Releases(v3.33.0)
  • v3.33.0(Sep 28, 2022)

    • make @Unmappable work with FieldMapper fields and KotlinMapper properties
    • rework the mapping logic for all bean related mappers (Bean, Field, Constructor, KotlinMapper)
    • clarify the @PropagateNull logic, ensure that it works with nested beans
    • ensure that bean mapper annotations work with lombok value and bean classes
    • add explicit support for byte[] -> BYTEA for Postgres. (#2109)
    • Revert lexer changes #1906 due to regressions
    • add missing jdbi3-postgis and jdbi3-json (tests) to the BOM
    • update build tooling for Java and Kotlin
    • internal kotlin packages are considered undocumented and no longer show up in the docs
    • Bean mapping now prefers setter annotations over getter annotations. (#2103)
    • Various methods that accept SQL statements now take CharSequence in preference to String (#2047)
    • Add a typesafe Sql class for SQL statements.
    • Upgrade Postgres driver to 42.5.0
    • call warm() correctly for SqlStatementCustomizer (#2040)
    Source code(tar.gz)
    Source code(zip)
  • v3.32.0(Jul 25, 2022)

    • Use Kotlin 1.7 ecosystem (compiler, plugin) but compile to Kotlin 1.5 compatibility
    • Add support for Eclipse LocationTech JTS data types with PostGIS. (#2072, #2074, thank you @bchapuis)
    • Fix exception in Handle#close() when underlying connection is closed (#2065)
    • Give access to per-batch row modification count (#2069, #2060, thank you @doppelrittberger)
    • Start new examples module for JDBI3 example code.
    Source code(tar.gz)
    Source code(zip)
  • v3.31.0(Jul 17, 2022)

    • Support binding parameters of type CharSequence (#2057, thanks @sman-81)
    • Fix Sql scripts to support BEGIN / END nested scripts (#2021, thanks @sman-81)
    • ResultIterables have additional convenience methods forEachWithCount and filter (#2056, thanks @sman-81)
    • upgrades to the build system to support external modules. This allows keeping the jdbi3-oracle12 module up to date.
    Source code(tar.gz)
    Source code(zip)
  • v3.30.0(Jun 2, 2022)

    3.30.0

    • Fix DefinedAttributeTemplateEngine lexer bug swallowing single-quoted text with escapes (#1906)
    • ANTLr 4.10.1
    • GSON 2.9.0 fixes CVE-2022-25647
    • Spring 5.3.20 fixes CVE-2022-22965
    • Promote TemplateEngine.NOP to a NoTemplateEngine class, for use with @UseTemplateEngine
    Source code(tar.gz)
    Source code(zip)
  • v3.29.0(May 21, 2022)

    This is a maintenance release. It bumps the minor because of a backwards incompatible change in the JdbiOtjPostgresExtension due to a change in the upstream otj-pg-embedded component.

    If you do not use this component, there are no significant changes over 3.28.0.

    • build now fully supports building with JDK 17
    • minor changes and cleanups (#2020, #2023)
    • always load kotlin plugin if using kotlin-sqlobject (#2023)
    • change BOM to resolve versions in the released bom version
    • update to otj-pg-embedded 1.0.1 (0.13.x started to crash on MacOS Monterey). This is a backwards incompatible change as the component changed the call signature of getJdbcUrl. This only affects the JdbiOtjPostgresExtension
    Source code(tar.gz)
    Source code(zip)
  • v3.28.0(Mar 8, 2022)

    Changed

    • Remove the antlr4-runtime dependency by inlining it into the core jar.

    Security

    • update baseline dependencies for known CVE (reported by dependabot)

    Housekeeping

    • [CI] add lgtm checks
    • [CI] build integration tests for inlined jar
    Source code(tar.gz)
    Source code(zip)
  • v3.27.2(Feb 18, 2022)

  • v3.27.1(Jan 25, 2022)

  • v3.27.0(Jan 6, 2022)

  • v3.26.1(Jan 4, 2022)

    DO NOT USE

    Serious regression: https://github.com/jdbi/jdbi/issues/1987

    3.26.2 coming soon.

    • Fix transaction callbacks working with nested transactions
    Source code(tar.gz)
    Source code(zip)
  • v3.26.0(Dec 21, 2021)

    Fixes

    • change annotation targets for Kotlin annotations to CLASS (fixes #1971)

    Changes

    • use h2 2.x for unit tests (prevents spurious "security" reports)
    • run more integration tests for postgres and dependency compatibility
    Source code(tar.gz)
    Source code(zip)
  • v3.25.0(Dec 18, 2021)

    • SPI change @Json String database type mappers now use @EncodedJson String instead (#1953)
    • Sql4JSqlLogger: fix NPE when using Script
    • fix using ConstructorMapper on empty generated keys results (#1955)
    • Handle: add new afterCommit and afterRollback transaction callbacks
    Source code(tar.gz)
    Source code(zip)
  • v3.24.1(Nov 17, 2021)

  • v3.24.0(Nov 10, 2021)

    3.24.0

    • Fix batch binding with mixed null and non-null primitives (#1901)
    • Add Arguments.setPreparedArgumentsEnabled to disable new preparable arguments feature
    • Add JUnit 5 support to the testing package.
    • Add interceptors for type inference for Row Mappers, Column Mappers and SQL Array types
    • Fix mapper lookup for Kotlin data types. Ensure that registered prefixes are used. Fixes #1944
    • RowMappers#register(RowMapper<?>) no longer allows Object as concrete parameter type.
    • Run ktlint and detekt on Kotlin code to improve code quality
    Source code(tar.gz)
    Source code(zip)
  • v3.23.0(Oct 9, 2021)

    • Rework and document importing bindings in guice definition modules
    • expose createKey() method in guice definition modules
    • Add no-op GuiceJdbiCustomizer
    • Fix annotation inheritance for non-direct supertypes (#1920)
    Source code(tar.gz)
    Source code(zip)
  • v3.22.0(Sep 13, 2021)

  • v3.21.0(Jul 15, 2021)

    • Fix sending Long types as INT8 instead of INT4 (#1902)
    • Updates to build and compilation (e.g. treat parameters/noparameters correctly)
    • Add a local mvnw binary to build without a local maven installation
    • Documentation updates and deploy fixes (kotlin docs work again)
    • Add a Metadata API to allow Database metadata access through the Handle (#1889)
    Source code(tar.gz)
    Source code(zip)
Owner
https://jdbi.org
null
An open source SQL database designed to process time series data, faster

English | 简体中文 | العربية QuestDB QuestDB is a high-performance, open-source SQL database for applications in financial services, IoT, machine learning

QuestDB 9.2k Sep 30, 2022
HasorDB is a Full-featured database access tool, Providing object mapping,Richer type handling than Mybatis, Dynamic SQL

HasorDB is a Full-featured database access tool, Providing object mapping,Richer type handling than Mybatis, Dynamic SQL, stored procedures, more dialect 20+, nested transactions, multiple data sources, conditional constructors, INSERT strategies, multiple statements/multiple results. And compatible with Spring and MyBatis usage.

赵永春 16 Sep 2, 2022
sql2o is a small library, which makes it easy to convert the result of your sql-statements into objects. No resultset hacking required. Kind of like an orm, but without the sql-generation capabilities. Supports named parameters.

sql2o Sql2o is a small java library, with the purpose of making database interaction easy. When fetching data from the database, the ResultSet will au

Lars Aaberg 1.1k Sep 27, 2022
🚀flink-sql-submit is a custom SQL submission client

??flink-sql-submit is a custom SQL submission client This is a customizable extension of the client, unlike flink's official default client.

ccinn 3 Mar 28, 2022
LINQ-style queries for Java 8

JINQ: Easy Database Queries for Java 8 Jinq provides developers an easy and natural way to write database queries in Java. You can treat database data

Ming Iu 638 Sep 24, 2022
Unified Queries for Java

Querydsl Querydsl is a framework which enables the construction of type-safe SQL-like queries for multiple backends including JPA, MongoDB and SQL in

Querydsl 4k Sep 29, 2022
CrateDB is a distributed SQL database that makes it simple to store and analyze massive amounts of machine data in real-time.

About CrateDB is a distributed SQL database that makes it simple to store and analyze massive amounts of machine data in real-time. CrateDB offers the

Crate.io 3.5k Oct 5, 2022
Official repository of Trino, the distributed SQL query engine for big data, formerly known as PrestoSQL (https://trino.io)

Trino is a fast distributed SQL query engine for big data analytics. See the User Manual for deployment instructions and end user documentation. Devel

Trino 6.2k Oct 2, 2022
The official home of the Presto distributed SQL query engine for big data

Presto Presto is a distributed SQL query engine for big data. See the User Manual for deployment instructions and end user documentation. Requirements

Presto 14k Sep 27, 2022
esProc SPL is a scripting language for data processing, with well-designed rich library functions and powerful syntax, which can be executed in a Java program through JDBC interface and computing independently.

esProc esProc is the unique name for esProc SPL package. esProc SPL is an open-source programming language for data processing, which can perform comp

null 676 Oct 1, 2022
A practical example to showcase Redis Streams and RediSearch in action

Redis Streams in Action A practical example to showcase Redis Streams in action. The goal is to process Twitter data in real-time for search and query

Abhishek Gupta 33 Aug 23, 2022
requery - modern SQL based query & persistence for Java / Kotlin / Android

A light but powerful object mapping and SQL generator for Java/Kotlin/Android with RxJava and Java 8 support. Easily map to or create databases, perfo

requery 3.1k Sep 25, 2022
jOOQ is the best way to write SQL in Java

jOOQ's reason for being - compared to JPA Java and SQL have come a long way. SQL is an "ancient", yet established and well-understood technology. Java

jOOQ Object Oriented Querying 5.1k Sep 29, 2022
Java code generator for calling PL/SQL.

OBridge OBridge provides a simple Java source code generator for calling Oracle PL/SQL package procedures. Supported input, output parameters and retu

Ferenc Karsany 20 Aug 30, 2022
A Java library to query pictures with SQL-like language

PicSQL A Java library to query pictures with SQL-like language. Features : Select and manipulate pixels of pictures in your disk with SQL-like dialect

Olivier Cavadenti 13 Jul 20, 2022
A Java library to query pictures with SQL-like language.

PicSQL A Java library to query pictures with SQL-like language. Features : Select and manipulate pixels of pictures in your disk with SQL-like dialect

null 13 Jul 20, 2022
EBQuery allows you to easily access databases through a REST API.

EBQuery Table of Contents Introduction - Enterprise Backend as a Service Requirements Getting started Using EBQuery Features Introduction - Enterprise

null 15 Nov 9, 2021