jDialects: a native SQL pagination tool extracted from Hibernate that supports more than 70 database dialects

jDialects ( https://git.oschina.net/drinkjava2/jdialects ) is a small Java project that collects most database dialects. It is usually used to create paging SQL and table building DDL statements. It can generate different database dialects according to different database dialects. SQL. Currently jDialects supports 75 database dialects, including SQLLite and Access which are not available in Hibernate. jDialects requires Java7 or above.

jDialects was originally developed for the jSqlBox project, but it is an independent project (the release package is only 90k in size and has no other third-party dependencies). As long as SQL is used, it can be used to create paging SQL and DDL for the corresponding database . For example, if pure JDBC, JdbcTemplate, DbUtils, etc. are used to operate native SQL persistence layer tools, and there are cross-database requirements (for example, unit tests need to run on H2 in-memory database and actual database MySql at the same time), you can use this tool to Implement paging across databases. Or, if you, like me, are developing a persistence layer tool that supports multiple databases, consider using jDialects.

The main part of the jDialects project is automatically generated by the code generation tool extracted from the Hibernate5.2.9 version, which also guarantees its code quality to a certain extent. See the jDiagen ( https://github.com/drinkjava2/jDiagen ) project for the code generation tool.

How to introduce jDialects in the project?
Download "jdialects-1.0.1.jar" and put it into the project library directory, or add it to the project's pom.xml file:
    <dependency>  
        <groupId>com.github.drinkjava2</groupId>  
        <artifactId>jdialects</artifactId>  
        <version>1.0.1</version>  
    </dependency>

Use
1) in the program to create paging across databases:
       Dialect d=guessDialect(dataSource); //judging the dialect type according to the data source, 
       //Dialect d=guessDialect(connection); //or judging the dialect type according to the connection 
       // Dialect d=Dialect.MySQL5Dialect; //Or manually specify the database dialect type
       String result=d.paginate(3, 10, "select * from users where id=?"); //Create pagination SQL 

   when the dialect is MySQL5Dialect, the result is : "select * from users where id=? limit 20, 10" 
   When the dialect is Oracle8iDialect, the result is: "select * from ( select row_.*, rownum rownum_ from ( select * from users where id=? ) row_ ) where rownum_ <= 30 and rownum_ > 20" 
   When the dialect is Oracle12cDialect, the result is: "select * from users where id=? offset 20 rows fetch next 10 rows only" 
   When the dialect is Sybase11Dialect, a DialectExcepiton exception is thrown and a prompt: "Sybase11Dialect" does not support physical pagination 
   ...

2) Create a cross-database DDL:
    private static String ddlSQL(Dialect d) {
        return "create table " + d.check("BufferPool") + "("//
                + d.BIGINT("f1") //
                + ", " + d.BIT("f2", 5) //
                + ", " + d.BLOB("f3") //
                + ", " + d.BOOLEAN("f4") //
                + ", " + d.INTEGER("f5") //
                + ", " + d.VARCHAR("f6", 8000) //
                + ", " + d.NUMERIC("ACCESS_LOCK", 8,2) //
                + ")" + d.engine(" DEFAULT CHARSET=utf8");
    }
    public static void main(String[] args) {//Run on different dialects
        System.out.println(ddlSQL(Dialect.MySQL57InnoDBDialect));
        System.out.println(ddlSQL(Dialect.SQLServer2012Dialect));
        System.out.println(ddlSQL(Dialect.Oracle10gDialect));   
    }


The running result of this example is:
   create table BufferPool(f1 bigint, f2 bit, f3 longblob, f4 bit, f5 integer, f6 varchar(8000), ACCESS_LOCK decimal(8,2))engine=innoDB DEFAULT CHARSET=utf8
   create table BufferPool( f1 bigint, f2 bit, f3 varbinary(MAX), f4 bit, f5 int, f6 varchar(MAX), ACCESS_LOCK numeric(8,2))
   create table BufferPool(f1 number(19,0), f2 number(1,0) ), f3 blob, f4 number(1,0), f5 number(10,0), f6 long, ACCESS_LOCK number(8,2))

example will log warning output when running: "BufferPool" and "ACCESS_LOCK" respectively Is a reserved word for DB2 and Teradata, which means that DialectException will be thrown if running on DB2Dialect or TeradataDialect database. To ensure portability, it is best to change the field with the warning to another name.
If you want to skip reserved word checking (not recommended), you can also write DDL in the following format:
       ddl= "create table BufferPool("//
                + "f1 "+d.BIGINT() //
                + ",f2 " + d.BIT(5) //
                + ",f3 " + d.BLOB() //
                + ",f4 " + d.BOOLEAN() //
                + ",f5 " + d.INTEGER() //
                + ",f6 " + d.VARCHAR(8000) //
                + ",ACCESS_LOCK " + d.NUMERIC(8,2) //
                + ")" + d.engine();


All types supported by jDialects are defined as follows:
BOOLEAN
DOUBLE
FLOAT
INTEGER
LONG(=BIGINT)
SHORT(=SMALLINT)
BIGDECIMAL(=NUMERIC)
STRING(=VARCHAR)
DATE
TIME
TIMESTAMP
BIGINT
BINARY
BIT
BLOB
CHAR
CLOB
DECIMAL
LONGNVARCHAR
LONGVARBINARY
LONGVARCHAR
NCHAR
NCLOB
NUMERIC
NVARCHAR
REAL
SMALLINT
TINYINT
VARBINARY
VARCHAR

3) About SQL functions
jDialects currently does not support cross-database SQL functions, mainly because SQL functions often have two situations in different databases, one is that the names and parameters are exactly the same, the other is that the changes are very large, and many are proprietary functions, regardless of the former Or the latter, it is not suitable to be represented by a general SQL function. In response to this, the jDialects code generation tool compares the functions of 75 dialects and writes them in the file "DatabaseDialects.xls" (which also includes paging and type definitions for various dialects), which can be used as a quick reference manual when database migration is required. .

The above are all jDialects documents. If you are unclear, you can view the project source code and unit tests. Finally, it should be emphasized that jDialects is just a text transformation tool. It performs different transformations on SQL according to different dialects. It is not a complete persistence tool itself, and must be used in conjunction with other persistence tools such as JDBC/DbUtils.

Appendix - The following are the 75 database dialects currently supported by jDialects:
AccessDialect
Cache71Dialect
CobolDialect
CUBRIDDialect
DataDirectOracle9Dialect
DB2390Dialect
DB2400Dialect
DB2Dialect
DbfDialect
DerbyDialect
DerbyTenFiveDialect
DerbyTenSevenDialect
DerbyTenSixDialect
ExcelDialect
FirebirdDialect
FrontBaseDialect
H2Dialect
HANAColumnStoreDialect
HANARowStoreDialect
HSQLDialect
Informix10Dialect
InformixDialect
Ingres10Dialect
Ingres9Dialect
IngresDialect
InterbaseDialect
JDataStoreDialect
MariaDB53Dialect
MariaDBDialect
MckoiDialect
MimerSQLDialect
MySQL55Dialect
MySQL57Dialect
MySQL57InnoDBDialect
MySQL5Dialect
MySQL5InnoDBDialect
MySQLDialect
MySQLInnoDBDialect
MySQLMyISAMDialect
Oracle10gDialect
Oracle12cDialect
Oracle8iDialect
Oracle9Dialect
Oracle9iDialect
OracleDialect
ParadoxDialect
PointbaseDialect
PostgresPlusDialect
PostgreSQL81Dialect
PostgreSQL82Dialect
PostgreSQL91Dialect
PostgreSQL92Dialect
PostgreSQL93Dialect
PostgreSQL94Dialect
PostgreSQL95Dialect
PostgreSQL9Dialect
PostgreSQLDialect
ProgressDialect
RDMSOS2200Dialect
SAPDBDialect
SQLiteDialect
SQLServer2005Dialect
SQLServer2008Dialect
SQLServer2012Dialect
SQLServerDialect
Sybase11Dialect
SybaseAnywhereDialect
SybaseASE157Dialect
SybaseASE15Dialect
SybaseDialect
Teradata14Dialect
TeradataDialect
TextDialect
TimesTenDialect
XMLDialect

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326301947&siteId=291194637