Hi Robert, First off, I'm sorry for the confusion. I could've researched this first. It appears that the DSLContext.ddl() API is really not well covered by integration tests. It works for basic cases (for which we have tests), but there need to be a lot more tests to cover everything. So, it's not surprising that you've run into issues so quickly.
I'll further comment inline. 2017-05-15 16:16 GMT+02:00 <[email protected]>: > Ah yes,so maybe a bug. The actual MySQL CREATE TABLE dump looks like this: > > CREATE TABLE acceptable_uses > ( > id INT(11) PRIMARY KEY NOT NULL AUTO_INCREMENT, > terms_and_conditions_id INT(11), > policy BLOB NOT NULL, > created_at DATETIME NOT NULL, > updated_at DATETIME NOT NULL > ); > > But what jOOQ spits out is this, which seems to be giving an error around > 'constraint' for my version of MySQL. > > create table `cloudability_dev`.`acceptable_uses`( > `id` int not null, > `terms_and_conditions_id` int null, > `policy` blob not null, > `created_at` timestamp not null, > `updated_at` timestamp not null, > constraint `KEY_acceptable_uses_PRIMARY` > primary key (`id`) > ); > > I'm more of a postgres guy but I think the errors are changing the type to > to timestamp and the constraint syntax. > Hmm, indeed, jOOQ doesn't "remember" that a DATETIME type was originally stored as SQLDataType cannot distinguish between DATETIME and TIMESTAMP. Usually, that's not a problem (since the more precise data type is used where the less precise one is expected) but when generating DDL, it would be desirable to retain the original type. The constraint syntax should be correct, though (although, I believe that MySQL ignores the constraint name). What MySQL version are you using? > Also looks to be an issue around auto increment. > Yes, that's clearly a bug. I've registered an issue for this: https://github.com/jOOQ/jOOQ/issues/6221 Up until jOOQ 3.9, there was no way to create identities at all through the DDL API: https://github.com/jOOQ/jOOQ/issues/5062 But with 3.9, these should be maintained also when using DSLContext.ddl(). > Maybe jOOQ could capture the actual DDL it uses during generation and just > ave those snippets as resources rather than re-reversing the DDL from the > classes? > Hmm, if the *actual* DDL is desirable, then I think it would be best if that DDL were kept around someplace, e.g. in some migration scripts in version control. The DSLContext.ddl() API is intended for use in cross compatibility setups, e.g. when the schema was originally from PostgreSQL and should now be installed on MySQL. Thanks again for pointing out these issues! Lukas -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
