Found while following the skill on a Jmix 2.8.2 project.
Problem: silent — and one section of the skill actively misleads for this case.
Task
A setting edited by a person in the UI: two numeric values, one for the whole application. The project already had two such settings entities; a third was needed.
Where
jmix-create-entity describes only a regular persistent entity: @JmixGeneratedValue UUID id, @Version, @InstanceName. A settings entity differs in every point: it extends io.jmix.appsettings.entity.AppSettingsEntity, its id is an integer managed by the add-on, the table holds exactly one row, @InstanceName is not needed, and defaults come from annotations in io.jmix.appsettings.defaults rather than a field initializer or @PostConstruct. jmix-create-liquibase-changelog also requires ${uuid.type} for ID, which is wrong here.
What happened
The structure had to be reverse-engineered from an existing settings entity and from the add-on jar. The integer default annotation was guessed by analogy as @AppSettingsIntegerDefault; the real name, @AppSettingsDefaultInt, was found only by listing io/jmix/appsettings/defaults/ inside jmix-appsettings-2.8.2.jar. The guessed name does not compile, so it could not ship, but it cost time.
Second, the "Required-field defaults" section insists that a required default must work through DataManager.create(). For a settings entity the add-on applies the default on first read, and a freshly created instance keeps null — so that rule does not apply here and misleads. Caught by compilation (the guessed annotation) and by reading the add-on sources (the defaults rule).
Suggested fix
Add a short "Application settings" section to jmix-create-entity with an applicability test ("the value is edited by a person in the UI and there is one for the whole application") and a sample: extend AppSettingsEntity, integer ID in the changelog instead of ${uuid.type}, no @InstanceName, the default annotations (@AppSettingsDefault, @AppSettingsDefaultInt, @AppSettingsDefaultLong, @AppSettingsDefaultBoolean, @AppSettingsDefaultDouble), and a note that "Required-field defaults" does not apply. In jmix-create-liquibase-changelog, one exception line about the integer ID. Also mention that such an entity needs the usual @EntityPolicy + @EntityAttributePolicy, and that one view serves all settings — appSettings.view. Related: #43 (routing gives no map of the add-ons).
Found while following the skill on a Jmix 2.8.2 project.
Problem: silent — and one section of the skill actively misleads for this case.
Task
A setting edited by a person in the UI: two numeric values, one for the whole application. The project already had two such settings entities; a third was needed.
Where
jmix-create-entitydescribes only a regular persistent entity:@JmixGeneratedValueUUID id,@Version,@InstanceName. A settings entity differs in every point: it extendsio.jmix.appsettings.entity.AppSettingsEntity, its id is an integer managed by the add-on, the table holds exactly one row,@InstanceNameis not needed, and defaults come from annotations inio.jmix.appsettings.defaultsrather than a field initializer or@PostConstruct.jmix-create-liquibase-changelogalso requires${uuid.type}forID, which is wrong here.What happened
The structure had to be reverse-engineered from an existing settings entity and from the add-on jar. The integer default annotation was guessed by analogy as
@AppSettingsIntegerDefault; the real name,@AppSettingsDefaultInt, was found only by listingio/jmix/appsettings/defaults/insidejmix-appsettings-2.8.2.jar. The guessed name does not compile, so it could not ship, but it cost time.Second, the "Required-field defaults" section insists that a required default must work through
DataManager.create(). For a settings entity the add-on applies the default on first read, and a freshly created instance keepsnull— so that rule does not apply here and misleads. Caught by compilation (the guessed annotation) and by reading the add-on sources (the defaults rule).Suggested fix
Add a short "Application settings" section to
jmix-create-entitywith an applicability test ("the value is edited by a person in the UI and there is one for the whole application") and a sample: extendAppSettingsEntity, integerIDin the changelog instead of${uuid.type}, no@InstanceName, the default annotations (@AppSettingsDefault,@AppSettingsDefaultInt,@AppSettingsDefaultLong,@AppSettingsDefaultBoolean,@AppSettingsDefaultDouble), and a note that "Required-field defaults" does not apply. Injmix-create-liquibase-changelog, one exception line about the integerID. Also mention that such an entity needs the usual@EntityPolicy+@EntityAttributePolicy, and that one view serves all settings —appSettings.view. Related: #43 (routing gives no map of the add-ons).