Found while following the skills on a Jmix 3.0.1 project.
Problem: silent — a column name is presented as a free choice derived from the field name.
Task
Entities carrying attributes named start, end and language, in a project targeting both PostgreSQL (the main store) and HSQLDB (the test store).
Where
jmix-create-entity step 6 ("Define columns with exact nullable, length, precision, and scale constraints") and the Entity Template's @Column(name = "NAME"); jmix-create-liquibase-changelog's column-definition guidance.
What happened
Both skills treat a column name as a free choice derived from the field name, and neither says that the derived name may be an SQL reserved word — which fails on one target and passes on another, so a green suite against the test store proves nothing about the real one.
Settling three names took writing a throwaway JDBC harness against the HSQLDB jar and reading PostgreSQL's pg_get_keywords(): HSQLDB 2.7.3 with default settings accepts START, END and LANGUAGE in DDL, INSERT, SELECT and UPDATE, while PostgreSQL 17 marks END reserved (unquotable) and START, LANGUAGE, TEXT, TYPE, NAME unreserved. So a prefixed rename of the end attribute's column is genuinely forced and LANGUAGE is genuinely fine — and neither fact is reachable from the skills.
The failure mode is the expensive one: Liquibase emits the createTable unquoted and EclipseLink emits t.END unquoted, so the defect appears only when the changelog is first applied to the production dialect — after compile, static analysis and a full green clean test have all passed against HSQLDB.
Caught in code review.
Suggested fix
Add one bullet where the column name is first chosen — a column name that is a reserved word in any targeted dialect must be renamed, and the check is per dialect, not per SQL standard, because the test store and the production store disagree. Naming the two checks would remove the search: select catcode from pg_get_keywords() where word = '<lower-case name>' for PostgreSQL, and for HSQLDB the note that its default settings accept SQL-standard keywords as identifiers, so it will not warn you. Worth stating in jmix-create-liquibase-changelog too, since that is where the name reaches the database, and worth naming the common offenders an entity field naturally produces: end, order, user, group, desc, references.
Found while following the skills on a Jmix 3.0.1 project.
Problem: silent — a column name is presented as a free choice derived from the field name.
Task
Entities carrying attributes named
start,endandlanguage, in a project targeting both PostgreSQL (themainstore) and HSQLDB (the test store).Where
jmix-create-entitystep 6 ("Define columns with exactnullable,length,precision, andscaleconstraints") and the Entity Template's@Column(name = "NAME");jmix-create-liquibase-changelog's column-definition guidance.What happened
Both skills treat a column name as a free choice derived from the field name, and neither says that the derived name may be an SQL reserved word — which fails on one target and passes on another, so a green suite against the test store proves nothing about the real one.
Settling three names took writing a throwaway JDBC harness against the HSQLDB jar and reading PostgreSQL's
pg_get_keywords(): HSQLDB 2.7.3 with default settings acceptsSTART,ENDandLANGUAGEin DDL, INSERT, SELECT and UPDATE, while PostgreSQL 17 marksENDreserved (unquotable) andSTART,LANGUAGE,TEXT,TYPE,NAMEunreserved. So a prefixed rename of theendattribute's column is genuinely forced andLANGUAGEis genuinely fine — and neither fact is reachable from the skills.The failure mode is the expensive one: Liquibase emits the
createTableunquoted and EclipseLink emitst.ENDunquoted, so the defect appears only when the changelog is first applied to the production dialect — after compile, static analysis and a full greenclean testhave all passed against HSQLDB.Caught in code review.
Suggested fix
Add one bullet where the column name is first chosen — a column name that is a reserved word in any targeted dialect must be renamed, and the check is per dialect, not per SQL standard, because the test store and the production store disagree. Naming the two checks would remove the search:
select catcode from pg_get_keywords() where word = '<lower-case name>'for PostgreSQL, and for HSQLDB the note that its default settings accept SQL-standard keywords as identifiers, so it will not warn you. Worth stating injmix-create-liquibase-changelogtoo, since that is where the name reaches the database, and worth naming the common offenders an entity field naturally produces:end,order,user,group,desc,references.