FLOAT and DOUBLE commented out in Dialect

[chrber]

Hi,

first of all: Thank you for this dialect.

I use this one:

<dependency>
            <groupId>com.github.gwenn</groupId>
            <artifactId>sqlite-dialect</artifactId>
            <version>0.1.0</version>
</dependency>

And when I look at the code of the SQLiteDialect class, I see:

public SQLiteDialect() {
		registerColumnType( Types.BIT, "boolean" );
		//registerColumnType(Types.FLOAT, "float");
		//registerColumnType(Types.DOUBLE, "double");
		registerColumnType( Types.DECIMAL, "decimal" );
		registerColumnType( Types.CHAR, "char" );
		registerColumnType( Types.LONGVARCHAR, "longvarchar" );
		registerColumnType( Types.TIMESTAMP, "datetime" );
		registerColumnType( Types.BINARY, "blob" );
		registerColumnType( Types.VARBINARY, "blob" );
		registerColumnType( Types.LONGVARBINARY, "blob" );

Plus, the comment says that this dialect is appropriate for Hibernate 3

/**
 * An SQL dialect for SQLite 3.
 */
public class SQLiteDialect extends Dialect {
	private final UniqueDelegate uniqueDelegate;

Could you tell why this is the case?

Thank you very much.
Kind regards.
Christian

[gwenn]

Because, in the super constructor you can find:

		registerColumnType( Types.FLOAT, "float($p)" );
		registerColumnType( Types.DOUBLE, "double precision" );

And because, with SQLite:
https://sqlite.org/datatype3.html#affinity
Column types are used only for affinity.
As far as as know, SQLite supports only double precision.

But you should also have a look at:
https://hibernate.atlassian.net/browse/HHH-10668

SQLite type affinity and limited support for altering table means that hibernate.hbm2ddl.auto cannot be set to modify nor create (I seem to recall that FK constraints are added after tables).
And when hibernate.hbm2ddl.auto is set to validate, Hibernate don't know that 'float', 'double', 'real' means the same thing for SQLite.

So depending on your convention / the column type(s) you actually use, you may have to tweak this dialect.

[chrber]

Because, in the super constructor you can find:

		registerColumnType( Types.FLOAT, "float($p)" );
		registerColumnType( Types.DOUBLE, "double precision" );

And because, with SQLite:
https://sqlite.org/datatype3.html#affinity
Column types are used only for affinity.
As far as as know, SQLite supports only double precision.

But you should also have a look at:
https://hibernate.atlassian.net/browse/HHH-10668

SQLite type affinity and limited support for altering table means that hibernate.hbm2ddl.auto cannot be set to modify nor create (I seem to recall that FK constraints are added after tables).
And when hibernate.hbm2ddl.auto is set to validate, Hibernate don't know that 'float', 'double', 'real' means the same thing for SQLite.

So depending on your convention / the column type(s) you actually use, you may have to tweak this dialect.

The Reason I asked was, because I have a table that has some REAL columns. During the automatic creation of entities, I use Intellij Ultimate for that, these column types are converted to Object in Java. I think the dialect is used for this conversion, but I must confess, I have no idea about how this creation actually works. The thing that puzzled me was that REAL is transformed into Object even though SQlite documentation states that REAL, DOUBLE, DOUBLE PRECISION, FLOAT should be transformed into REAL (https://www.sqlite.org/datatype3.html#datatypes_in_sqlite). Could you enlighten me? Because this fact keeps me from enjoying auto creation of Java entities from my database. Thank you and kind regards. Christian

[gwenn]

As far as I know, you cannot generate Java entities from your database.
And the problem may be related to SQLiteDialect.
But also related to SQLite JDBC driver.
I am afraid you will have to investigate on your own.

[Cypher01]

I was also confused by these commented lines. But as I didn't experience any problems, I suggest to remove the two lines or even better replace them by comments that explain quickly something like "you don't find double and float here because they are in the super constructor".