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
  • rename TestingInitializers for pmd

    rename TestingInitializers for pmd

    pmd introduced name checking in 6.51.0 for TestClassWithoutTestCases. It considers all classes starting with Test a test class and will croak if they don't contain tests. This hits the TestingInitializers class which is overdue for refactoring anyway.

    • rename the class
    • move the User pojo that is used in multiple places into this class
    • move the UserMapper which is used in multiple places into this class
    • do the same thing for Something (this is an actual bean)
    • re-enable the TestClassWithoutTestCases rule in PMD.
    cleanup good-first-issue 
    opened by hgschmie 0
  • Drop Java 8 support in 2023

    Drop Java 8 support in 2023

    Java 21 is the next LTS, coming out in September 2023. At this point, we would need to support four LTS versions: 8, 11, 17 and 21.

    I propose that we drop Java 8 support latest on that date and move to Java 11 as the base line.

    opened by hgschmie 0
  • Extract annotations to separate Maven module?

    Extract annotations to separate Maven module?

    In our project we would like to use JDBI annotations on Java types resided in a shared Maven module which doesn't depend on any database code. It would be nice to move JDBI annotations to a separate lightweight Maven module (like it is done for Jackson annotations), so code in the shared module can only see the annotations types, not everything.

    Our current solution is to have the jdbi dependency in 'provided' scope in the shared Maven module.

    improvement question investigation needed 
    opened by agavrilov76 2
  • Mappers that allow partial mapping should support no columns mapped to them

    Mappers that allow partial mapping should support no columns mapped to them

    FieldMapper, Bean/PojoMapper and the KotlinMapper do support creating result objects even if not all attributes are mapped. Field/Bean mapper leave attributes unset, the KotlinMapper will succeed even if using c'tor mapping if default values are present.

    However, all of them fail with Mapping fields for type %s didn't find any matching columns in result set if the result set contains columns but none matches onto the mapper. This is especially tragic when using a JoinRowMapper that can spread many return columns across multiple objects. At least one must hit the mapper, otherwise there is an exception.

    Why is that? Is that reasonable? Should it be configurable?

    Needs investigation and maybe code changes.

    feature improvement investigation needed 
    opened by hgschmie 0
  • @UseClasspathSqlLocator should support custom lookup paths

    @UseClasspathSqlLocator should support custom lookup paths

    Discussed in https://github.com/jdbi/jdbi/discussions/2202

    Originally posted by wKoja November 21, 2022 Is there a way to tell JDBI to use a custom path with this annotation instead of having to make it match the interface's fully qualified name? Similar to how ClasspathSqlLocator.create().locate('custom/path/to/custom-query) works.

    improvement answered 
    opened by hgschmie 0
Releases(v3.36.0)
  • v3.36.0(Dec 31, 2022)

    • fix concurrency issue when copying the config registry (#2236), thanks @npetryk
    • Support class-level (static) instance fields for JdbiExtension and its subclasses.
    • Add jdbi3-testing support for testcontainer based databases, see Using Testcontainers for details
    Source code(tar.gz)
    Source code(zip)
  • v3.35.0(Dec 3, 2022)

    • Fix JdbiFlywayMigration to work with Flyway 9 (#2179, thanks @broccolai)
    • ResultIterable.useIterator and ResultIterable.withIterator new helper methods to close iterator resources
    • add handle and resource leak checking to all unit tests, fix unit tests to not leak any resources
    • add resource leak checking support to the JdbiExtension JUnit5 testing framework
    • support lifecycle listeners for Handle and StatementContext
    • fixes and updates to the build system, additional docs for contributing, IDE code style support for IntelliJ and Eclipse
    • doc updates for Kotlin code
    • add Kotlin mapTo(KClass<*>) extension function to ResultBearing
    • SqlObject Consumer now accepts Consumer<Stream> and Consumer<Iterator> forms
    • deprecate misnamed setTransactionIsolation method, add setTransactionIsolationLevel to the handle
    • deprecate misnamed release method, add releaseSavepoint to the handle
    • add missing isInTransaction method to Transactional, bringing it to par to the handle set of methods
    • add H2 option string, user and password methods to JdbiH2Extension
    • ReflectionMappers: add accessibleObjectStrategy to allow skipping setAccessible calls for FieldMapper in particular
    • minimal support for testing with other databases in JdbiGenericExtension
    • Dependabot warnings for Postgres and H2, upgrade to 42.5.1 and 2.1.214 respectively.
    Source code(tar.gz)
    Source code(zip)
  • v3.34.0(Oct 5, 2022)

    • jdbi3-generator will now support any Java 8+ version without generating compile-time warnings (#2128)
    • AbstractArgumentFactory also need to check for supertypes when the generic argument is not a class (fixes #2026)
    • Replace @Unmappable with @JdbiProperty so you can configure both mapping and binding flexibly
    Source code(tar.gz)
    Source code(zip)
  • 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.9k Jan 1, 2023
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 Dec 28, 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
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.

赵永春 17 Oct 27, 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 641 Dec 28, 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 4.1k Dec 31, 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.6k Jan 2, 2023
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 990 Dec 27, 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.9k Dec 31, 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 14.3k Dec 30, 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 35 Dec 19, 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 Jan 5, 2023
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.3k Jan 4, 2023
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 21 Oct 7, 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 16 Dec 25, 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 16 Dec 25, 2022
Free universal database tool and SQL client

DBeaver Free multi-platform database tool for developers, SQL programmers, database administrators and analysts. Supports any database which has JDBC

DBeaver 29.8k Jan 1, 2023