Flyway by Redgate • Database Migrations Made Easy.

Overview

Flyway by Redgate Build Status Maven Central GitHub license

Database Migrations Made Easy.

Flyway

Evolve your database schema easily and reliably across all your instances.

Simple, focused and powerful.

Works on

Windows, macOS, Linux, Docker, Java and Android

Supported build tools

Maven and Gradle

Supported databases

Oracle, SQL Server, DB2, MySQL, Aurora MySQL, MariaDB, Percona XtraDB Cluster, PostgreSQL, Aurora PostgreSQL, Redshift, CockroachDB, SAP HANA, Sybase ASE, Informix, H2, HSQLDB, Derby, SQLite, Firebird

Third party plugins

SBT, Ant, Spring Boot, Grails, Play!, DropWizard, Grunt, Griffon, Ninja, ...

Documentation

https://flywaydb.org

About

Flyway is brought to you by Redgate with the help of many contributors.

How to contribute

https://flywaydb.org/documentation/contribute

License

Copyright © Red Gate Software Ltd 2010-2020

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Trademark

Flyway is a registered trademark of Boxfuse GmbH, owned by Red Gate Software Ltd.

Issues
  • Output to sql file instead of commiting against the DB

    Output to sql file instead of commiting against the DB

    Original author: [email protected] (March 18, 2013 05:59:16)

    HI,

    We're just starting to use flyway in our project and so far it looks really good. It's gonna help us a lot automatically upgrade all of our different environments.

    One thing that would be nice is way to combine all or specific sql versions into one sql file. We would use this because we can't tell our client's IT department (big client) to use flyway for upgrading the prod database and we obviously don't have access to that database. Currently the only way we can get the database upgraded is by sending them an SQL file (which they run on their stage before prod).

    In theory we could manually combine all the relevant files ourselves but that could be a bit cumbersome and error-prone. Also things like placeholders would need to be replaced manually (search & replace but still) with the proper value, again error-prone.

    We use maven so a new goal should do it.

    That said thanks for the great work!

    Original issue: http://code.google.com/p/flyway/issues/detail?id=452

    t: feature m: Core 
    opened by flyway 62
  • Condense existing migrations into a new initial one

    Condense existing migrations into a new initial one

    Original author: [email protected] (March 29, 2013 11:29:05)

    We have hundred migrations, tabels created and drops, unnecessary fields and so on. It will be great to add cummulative migration which can be applied to clean schema to optimize initial migration.

    Original issue: http://code.google.com/p/flyway/issues/detail?id=470

    t: feature 
    opened by flyway 62
  • Clean tries to drop a function from an extension and fails

    Clean tries to drop a function from an extension and fails

    Original author: [email protected] (May 11, 2012 10:11:31)

    We are using PostgreSQL 9.1 and are using the uuid-ossp extension. Clean tries to drop one of its functions. The extension has been installed manually as it required adding binaries to the DBMS.

    Any way to work around this?

    FlywayException: Error executing statement at line 64: DROP FUNCTION IF EXISTS "public"."uuid_nil"() CASCADE Occured in com.googlecode.flyway.core.migration.sql.SqlStatement in method execute, line number 78 Caused by org.postgresql.util.PSQLException: ERROR: cannot drop function uuid_nil() because extension uuid-ossp requires it Hint: You can drop extension uuid-ossp instead. Occured in org.postgresql.core.v3.QueryExecutorImpl in method receiveErrorResponse, line number 2102

    Original issue: http://code.google.com/p/flyway/issues/detail?id=257

    t: bug d: PostgreSQL r: fixed 
    opened by flyway 53
  • Gradle plugin

    Gradle plugin

    A gradle plugin based on the Flyway 2.x series (original).

    This plugin is integrated into the Maven build using the gradle-maven-plugin to invoke the gradle build. The gradle wrapper is invoked so that the maven packaging phase has the compile jars in the target folder. This allows maven to pick up the jars in subsequent phases, like install.

    opened by ben-manes 40
  • Database Downgrade

    Database Downgrade

    Original author: [email protected] (September 20, 2012 07:06:48)

    I am new to flyway and currently evaluating how/if we could use flyway in our project.

    What I really miss, is the possibility to downgrade a database to a previous version. Migrating to the newest version is fine when you start from scratch and when you have no (production) data in a database. But in the case you have to step back you still have to do everything manually.

    In my opinion, this would not very hard to implement. You just have to provide some additiona scripts with a __dowgrade suffix that revert a certain version and do the things you did from the other direction.

    At the moment, this is the main issue regarding use/don't use flyway. Stepping back seems to be still clumsy and when it is necessary to do a downgrade manually, the question arises to do the migration manually also to be consistent.

    Original issue: http://code.google.com/p/flyway/issues/detail?id=334

    t: feature 
    opened by flyway 40
  • added support for non-transactional SQL migrations

    added support for non-transactional SQL migrations

    fixes #1026

    • added new Resolver and Executor classes
    • NTSqlMigrationResolver works on the files prefixed with "NTV", currently hardcoded. (Looking forward for suggestions over this)
    • Added the new resolver in migrationResolvers while creating CompositeMigrationResolver instance
    • added small test for new resolver
    opened by Omie 37
  • Ignore line endings when calculating checksums

    Ignore line endings when calculating checksums

    Original author: [email protected] (September 28, 2011 15:49:50)

    We ran into the following problem.

    Developer on Mac/Linux creates a sql migration file and checks it into Git. It runs on production (which is on Linux) just fine.

    Then a Windows developer takes a copy of the production database and loads it into their local machine. But when they pulled the sql migration file from Git, it automatically converted the line endings to CRLF (Windows style). Now Flyway validate and migrate fail saying there is a checksum mismatch.

    One solution I can think of would be to ignore line endings when doing the checksum.

    Original issue: http://code.google.com/p/flyway/issues/detail?id=167

    t: bug m: Core 
    opened by flyway 36
  • Support Multiple Migrations within a single Transaction

    Support Multiple Migrations within a single Transaction

    Original author: [email protected] (April 24, 2013 05:01:42)

    When upgrading a database I would expect all un-applied migrations to be applied within the same transaction. Currently each migration runs within its own transaction.

    My use-case looks something like this:

    1. Version 1.0 is deployed into Production
    2. Developers work on features for Version 2.0, each creating a migration script matching their new feature.
    3. As development progresses, V2.x migrations, and the associated application, are put into QA.
    4. Eventually we decide we've done enough, and want to release v2, and it's myriad migration scripts.
    5. When we run the deployment against v1 in production we expect all the v2.x migrations to run, and if there is a problem with any of them, then the database is rolled back, and we revert the application to v1 while we figure out what went wrong.

    We really don't want some of the v2 scripts to be committed to the production database.

    We're using Postgres, so DDL rolls back nicely.

    I'm happy to do the change, if nobody else is interested, but it seems like an "obvious" feature to me. None of your competition seem to offer it either. Am I missing something?

    Original issue: http://code.google.com/p/flyway/issues/detail?id=484

    t: feature m: Core 
    opened by flyway 34
  • Sybase ASE support

    Sybase ASE support

    Original author: [email protected] (October 24, 2012 08:08:44)

    Hi, your frameworks looks very good but it'd be fine to support Sybase. It's very similar to SQL Server.

    I'll be looking forward for this enhancement if accepted.

    Thanks in advance.

    Original issue: http://code.google.com/p/flyway/issues/detail?id=350

    t: feature 
    opened by flyway 34
  • support sbt 1.0

    support sbt 1.0

    sbt 1.0.0 released http://developer.lightbend.com/blog/2017-08-11-sbt-1-0-0/

    sbt 1.0.x is not compatible with sbt 0.13.x. need cross build or migrate to 1.0.

    t: feature m: SBT 
    opened by xuwei-k 30
  • Supports OpenTelemetry JDBC prefix.

    Supports OpenTelemetry JDBC prefix.

    This PR adds support for jdbc:otel: prefix, which can be used by OpenTelemetry Manual Instrumentation: https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/jdbc/library.

    opened by donbeave 1
  • Announcement: Changes to Flyway for the V8 release

    Announcement: Changes to Flyway for the V8 release

    This issue explains the changes we intend to make to Flyway for the V8 release.

    The jump from V7 to V8 will be a major version change, as per Semantic Versioning. Users should expect breaking and non-backward compatible changes to be introduced.

    We're sharing this early so you can anticipate if the breaking changes will affect you. Any feedback on these proposals are welcome.

    We intend to release Flyway V8 at the end of Q3 2021. Some work may be released before then under feature flags, undocumented features, etc.

    For those following the roadmap, V8 won't necessarily include everything in there. Some features slated for 'V8' may end up in later V8 releases (e.g. 8.1.0).

    Flyway V8 proposed changes

    API Changes

    These things have been marked as deprecated for a long time, and will be removed.

    • -json flag (replaced with -outputType=json)
      • Command line will produce invalid argument error
    • SPRING_JDBC and UNDO_SPRING_JDBC migration types
    • installedOn field in InfoOutput
      • To be replaced with installedOnUTC
      • To be marked with a @Deprecated annotation
    • validationError field in ValidateResult
      • To be replaced with errorDetails
      • To be marked with a @Deprecated annotation
    • validateResult constructor
      • To be replaced with a different constructor
      • To be marked with a @Deprecated annotation

    Architecture changes

    We're introducing an extension mechanism that will allow optional functionality to loaded at runtime. Extensions can be optionally dropped in to any Flyway installation to enable new capabilities.

    We're moving HashiCorp Vault from Flyway's core to an extension.

    In the course of time we intend to open this up to allow the Flyway community to write their own plugins for new capabilities.

    One aim of this is to enable the community to create their own extensions for the wide range of requested databases that Flyway doesn't yet support. This means it'll be unnecessary to have a pull request accepted to the main Flyway codebase to make Flyway compatible with new databases.

    Instead, users will be free to create and use their own extensions, which will be compatible with a mainline release of Flyway. You therefore won't need to depend on a community owned fork of the whole codebase. In this way, we hope to nurture an ecosystem of 'Community Supported' database extensions.

    New functionality

    • Google Cloud Spanner & Big Query support will be promoted from beta to general availability
    • New secrets managers: Dapr, and Google Secret Manager
    • A way to configure the logger that Flyway will use (current behavior is that Flyway picks up any logger it finds on the classpath in a pre-defined order of precedence)

    Drop Android support

    We aren't convinced that Flyway is used very much on Android,

    Furthermore, it looks like Android support has been broken for a while. See https://github.com/flyway/flyway/issues/970.

    We're intending to remove the guarantee of support for Android for V8.

    To mark as deprecated on the V8 release

    These features will continue to work in V8, but will be dropped at some future release.

    • defaultSchema and schemas parameters will be re-worked to be less confusing

    Database support timeline

    As per our database support policy, the following database versions are no longer supported in Community edition. They are however still supported in Flyway Teams edition:

    • SQL Server 2016
    • MariaDB 10.2
    • MySQL 5.7
    • Sybase ASE 16.2
    • Postgres 9.5/9.6
    • DB2 11.1
    • Apache Derby 10.13
    t: announcement 
    opened by juliahayward 1
  • Flyway in CMD misinterpreting quotes on the command line

    Flyway in CMD misinterpreting quotes on the command line

    Latest version, reported by Joshua. He has a situation where a URL is passed in on the command line as so:

    flyway info -url='jdbc:oracle:thin:@//REDACTED:1521/REDACTED'

    In Powershell this is fine. In bash this is fine (tested on Ubuntu 18.04) In cmd (Windows command prompt, old-school) this FAILS with

    ERROR: No database found to handle 'jdbc:oracle:thin:@//REDACTED:1521/REDACTED'

    That is, the single quotes were understood to be part of the URL. Can we catch this odd case? It specifically applies to single-quotes; double-quotes are fine.

    opened by juliahayward 0
  • When will Dameng database be supported

    When will Dameng database be supported

    https://www.dameng.com/

    When does flyway support Dameng database?

    t: feature s: pull request welcome t: database support 
    opened by ATM006 0
  • Fix PostgreSQL CopyManager class loading error when flyway API used from WildFly EJB

    Fix PostgreSQL CopyManager class loading error when flyway API used from WildFly EJB

    Hello

    When i try to use flyway migration API from WildFly Standalone session bean on application start i got Exception: ... Caused by: org.flywaydb.core.api.FlywayException: Unable to find PostgreSQL CopyManager class at deployment.service-1.0.ear//org.flywaydb.core.internal.database.postgresql.PostgreSQLCopyParsedStatement.execute(PostgreSQLCopyParsedStatement.java:85) at deployment.service-1.0.ear//org.flywaydb.core.internal.sqlscript.DefaultSqlScriptExecutor.executeStatement(DefaultSqlScriptExecutor.java:212) at deployment.service-1.0.ear//org.flywaydb.core.internal.sqlscript.DefaultSqlScriptExecutor.execute(DefaultSqlScriptExecutor.java:128) at deployment.service-1.0.ear//org.flywaydb.core.internal.resolver.sql.SqlMigrationExecutor.executeOnce(SqlMigrationExecutor.java:78) at deployment.service-1.0.ear//org.flywaydb.core.internal.resolver.sql.SqlMigrationExecutor.lambda$execute$0(SqlMigrationExecutor.java:67) at deployment.service-1.0.ear//org.flywaydb.core.internal.database.DefaultExecutionStrategy.execute(DefaultExecutionStrategy.java:27) at deployment.service-1.0.ear//org.flywaydb.core.internal.resolver.sql.SqlMigrationExecutor.execute(SqlMigrationExecutor.java:66) at deployment.service-1.0.ear//org.flywaydb.core.internal.command.DbMigrate.doMigrateGroup(DbMigrate.java:354) ...

    WildFly jdbc connection configured using JBoss module - JBoss hand made modules solution with custom classloader. Standard way to access this module for developer is to add something like this to EJB jar MANIFEST.MF: Dependencies: org.postgresql

    But this is not the case for postgres flyway migrations. While EJB bean can use any class from jdbc driver, migration executor still can't see CopyManager.

    Issue was: PostgreSQLCopyParsedStatement.execute(...) method try to load CopyManager class from dataSource connection class loader.

    It is good solution for most cases, but it does not work with JBoss modules classloader. To fix this i suggest to try connection class loader first (for most cases) and then try current class loader (to support JBoss/Wildfly EJB)

    Tested with WildFly 22.0.1.Final and JDK 11.0.8 Can be reproduced with docker container: jboss/wildfly:22.0.1.Final

    FlywayStartup.java.zip

    opened by ptucha 3
  • Support Java Modules (jpms)

    Support Java Modules (jpms)

    Which version and edition of Flyway are you using?

    7.9.1

    If this is not the latest version, can you reproduce the issue with the latest one as well? (Many bugs are fixed in newer releases and upgrading will often resolve the issue)

    N/A

    Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin)

    All

    Which database are you using? (Type & version)

    N/A

    Which operating system are you using?

    N/A

    What did you do? (Please include the content causing the issue, any relevant configuration settings, the SQL statement(s) that failed (if any), and the command you ran)

    I want to use Flyway in a Java module application having migrations files located in several different modules.

    Flyway is lacking support for loading migrations from resources encapsulated in java modules.

    In a modulalar Java application non-class-file resources in a module are encapsulated by default, and hence cannot be located from outside the module unless their effective package is open as it is discussed here.

    For example, resource migration files under the db/migration directory cannot be longer loaded by the application class-loader from the Flyway module unless the application module explicitly opens the db.migration package.

    Note that if the resource path name is NOT a valid Java identifier, the resources are not encapsulated and therefore will be accessible from outside of the module. See my answer to the same stack overflow question for details and a complete example. That is, if the migration are located in db-xxx/migration Flyway will be able to find them! Something that can be used as a workaround for loading issues.

    Also note that db.migration package can only be present in one single module of the module path at the time. Otherwise, java will complain about a package being present in several modules.

    As discussed in the SO, the best practices are to use the resource-lookup methods in Class or Module which can locate any resource in the module. A possible solution is to delegate the resource loading to application modules via the Java service loader mechanism. Flyway can define a common interface to list available migration resource locators which a Java module would implement and provide in their module-info. Flyway can obtain all the available implementations of the interface from the module path and get access to the migration resources.

    What did you expect to see?

    I expected Flyway to provide a mechanism to locate migration files in a modular Java application.

    What did you see instead?

    Put migration files under a resource directory named with a non-valid Java identifier making the migrations are effectively not-encapsulated and there accessible for Flyway module. See this for details.

    t: feature 
    opened by agavrilov76 9
  • Include a Build Service in the Gradle plugin

    Include a Build Service in the Gradle plugin

    Feature request: Include a Build Service in the Gradle plugin.

    Background/motivation

    We have some tasks that need a postgres database to be running while they execute. Rather than requiring that everyone have postgres running (or even installed), we use docker to start up a container with postgres. We also use the flyway gradle plugin's flywayMigrate task to set up the DB in this container. We shut down this container before the build finishes.

    To accomplish this, we have the following tasks:

    • startPostgres — starts a DB container
    • flywayMigrate — sets up the DB in the container; depends on startPostgres
    • generateJooq — generates source code from DB; depends on flywayMigrate
    • generateDiagrams — generates diagrams from DB; depends on flywayMigrate
    • stopPostgres — tears down the container; finalizer for startPostgres, mustRunAfter generateJooq and generateDiagrams

    This works correctly: things happen in the right order, and they always execute when they are neede, and they always execute when they are needed.

    However, it isn't as efficient as it could be. The generate* jobs only execute when necessary — they correctly detect when they are up-to-date, but if I run either/both the generate* tasks twice in a row without changing any of the files they depend on, the startPostgres, flywayMigrate, and stopPostgres tasks are all executed the second time even though none of them are necessary.

    In researching this, it appears others have run into the same sort of problem: we aren't the only ones who would like to be able to start a DB container hand have flyway migrate it as part of our build.

    Build Services

    I asked about this on the Gradle Slack and the consensus was that the right solution is to use one or more build services in place of the startPostgres/stopPostgres and flywayMigrate tasks.

    From the Gradle documentation for Build Services:

    Sometimes, is it useful for several tasks to share some state or resource. For example, tasks might share a cache of pre-computed values in order to do their work faster. Or tasks might do their work using a web service or database instance.

    Gradle allows you to declare build services to represent this state. A build service is simply an object that holds the state for tasks to use. Gradle takes care of the service lifecycle, and will create the service instance only when it is required and clean it up once it is no longer required. ... In addition to using a build service from a task, you can use a build service from ... another build service.

    Proposal

    The flywayMigrate task has a nice mapping from Gradle's DSL to Flyway's configuration, but build services cannot invoke tasks. It would be nice if the Flyway Gradle plugin also provided a BuildService implementation that used the same style of DSL for configuring Flyway to operate as a build service.

    Ideally, such a FlywayBuildService would optionally be able to interoperate with another build service that manages a starting/stopping a database (perhaps in a docker container, as in the example above), and would lazily get the connection information for the database. (This would allow containers to use a random available port, rather than a predetermined port, for example.)

    t: feature 
    opened by xenomachina 0
  • Use Timestamp with Time zone in PostgreSQL

    Use Timestamp with Time zone in PostgreSQL

    See https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_timestamp_.28without_time_zone.29

    opened by gastaldi 1
  • Added Vertica 10_1 support

    Added Vertica 10_1 support

    Added Vertica 10.1 support. Used existing vertica_9_pr as starting point, improved, fixed some bugs and tested on newer Vertica version.

    Tested for Vertica 10.1.

    I am in contact with Vertica team and if you need Docker for testing on testcontainers to accept this PR, you can contact me and we will try to come up with something, because official Docker container for Vertica will be released soon.

    I am sure there are people waiting for Vertica support from Flyway, so I hope this PR can help them.

    opened by drachich 4
  • AWS Azure AD support

    AWS Azure AD support

    AWS Redshift supports Azure Active Directory. We could test + document how to use this with Flyway.

    https://docs.aws.amazon.com/singlesignon/latest/userguide/azure-ad-idp.html

    t: feature 
    opened by MikielAgutu 0
Releases(flyway-7.15.0)
Owner
Flyway by Boxfuse
Database Migrations Made Easy by @boxfuse
Flyway by Boxfuse
R2DBC Driver for Oracle Database

About Oracle R2DBC The Oracle R2DBC Driver is a Java library that supports reactive programming with Oracle Database. Oracle R2DBC implements the R2DB

Oracle 104 Sep 15, 2021
Change data capture for a variety of databases. Please log issues at https://issues.redhat.com/browse/DBZ.

Copyright Debezium Authors. Licensed under the Apache License, Version 2.0. The Antlr grammars within the debezium-ddl-parser module are licensed unde

Debezium 5.3k Sep 7, 2021
Speedment is a Stream ORM Java Toolkit and Runtime

Java Stream ORM Speedment is an open source Java Stream ORM toolkit and runtime. The toolkit analyzes the metadata of an existing SQL database and aut

Speedment 1.9k Sep 13, 2021
MariaDB Embedded in Java JAR

What? MariaDB4j is a Java (!) "launcher" for MariaDB (the "backward compatible, drop-in replacement of the MySQL(R) Database Server", see FAQ and Wiki

Michael Vorburger ⛑️ 625 Sep 15, 2021
The public release repository for SUSTech SQL (CS307) course project 2.

CS307 Spring 2021 Database Project 2 1. Source code Download link: For java: https://github.com/NewbieOrange/SUSTech-SQL-Project2-Public For python: h

null 15 Jun 19, 2021
Multi-DBMS SQL Benchmarking Framework via JDBC

BenchBase BenchBase (formerly OLTPBench) is a Multi-DBMS SQL Benchmarking Framework via JDBC. Table of Contents Quickstart Description Usage Guide Con

CMU Database Group 26 Sep 9, 2021
光 HikariCP・A solid, high-performance, JDBC connection pool at last.

HikariCP It's Faster.Hi·ka·ri [hi·ka·'lē] (Origin: Japanese): light; ray. Fast, simple, reliable. HikariCP is a "zero-overhead" production ready JDBC

Brett Wooldridge 15.7k Sep 14, 2021
SQL made uagliò.

GomorraSQL is an easy and straightforward interpreted SQL dialect that allows you to write simpler and more understandable queries in Neapolitan Langu

Donato Rimenti 844 Sep 14, 2021
Main Liquibase Source

Liquibase Liquibase helps millions of teams track, version, and deploy database schema changes. This repository contains the main source code for Liqu

Liquibase 2.8k Sep 7, 2021
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 621 Aug 31, 2021
Transactional schema-less embedded database used by JetBrains YouTrack and JetBrains Hub.

JetBrains Xodus is a transactional schema-less embedded database that is written in Java and Kotlin. It was initially developed for JetBrains YouTrack

JetBrains 920 Sep 11, 2021
Transactional schema-less embedded database used by JetBrains YouTrack and JetBrains Hub.

JetBrains Xodus is a transactional schema-less embedded database that is written in Java and Kotlin. It was initially developed for JetBrains YouTrack

JetBrains 858 Mar 12, 2021
Event capture and querying framework for Java

Eventsourcing for Java Enabling plurality and evolution of domain models Instead of mutating data in a database, Eventsourcing stores all changes (eve

Eventsourcing, Inc. 404 Jul 13, 2021
Realm is a mobile database: a replacement for SQLite & ORMs

Realm is a mobile database that runs directly inside phones, tablets or wearables. This repository holds the source code for the Java version of Realm

Realm 11.2k Sep 10, 2021
eXist Native XML Database and Application Platform

eXist-db Native XML Database eXist-db is a high-performance open source native XML database—a NoSQL document database and application platform built e

eXist-db.org 315 Sep 16, 2021
A tool based on mysql-connector to simplify the use of databases, tables & columns

Description A tool based on mysql-connector to simplify the use of databases, tables & columns. This tool automatically creates the databases & tables

nz 3 Aug 17, 2021
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.2k Sep 7, 2021
Mystral (pronounced "Mistral") is an efficient library to deal with relational databases quickly.

Mystral An efficient library to deal with relational databases quickly. A little request: read the Javadoc to understand how these elements work in de

null 13 Aug 30, 2021