This documentation is for the unreleased development version of jOOQ. Click on the above version links to get this documentation for a supported version of jOOQ.
Visibility Modifier (per forced type)
Applies to ❌ Open Source Edition ✅ Express Edition ✅ Professional Edition ✅ Enterprise Edition
There are a few cases where the visibility of individual columns should be reduced, e.g. to private
in order to hide a technical column from user code. For those cases, the forced type configuration can be used again to match columns, and apply a visibility:
<configuration> <generator> <database> <forcedTypes> <forcedType> <!-- Possible values for visibilityModifier - DEFAULT : The default per language (Java: public, Kotlin, Scala: implicit public) - NONE : Do not generate visibility modifiers - PUBLIC : Generate explicit public modifiers (Java, Kotlin) - INTERNAL : Generate explicit internal modifiers (Kotlin) - PRIVATE : Generate explicit private modifiers (Java, Kotlin, Scala) --> <visibilityModifier>PRIVATE</visibilityModifier> <includeExpression>(?i:CREATED|MODIFIED)_(?i:AT|BY)</includeExpression> </forcedType> </forcedTypes> </database> </generator> </configuration>
See the configuration XSD, standalone code generation, and maven code generation for more details.
new org.jooq.meta.jaxb.Configuration() .withGenerator(new Generator() .withDatabase(new Database() .withForcedTypes( new ForcedType() // Possible values for visibilityModifier // - DEFAULT : The default per language (Java: public, Kotlin, Scala: implicit public) // - NONE : Do not generate visibility modifiers // - PUBLIC : Generate explicit public modifiers (Java, Kotlin) // - INTERNAL : Generate explicit internal modifiers (Kotlin) // - PRIVATE : Generate explicit private modifiers (Java, Kotlin, Scala) .withVisibilityModifier(VisibilityModifier.PRIVATE) .withIncludeExpression("(?i:CREATED|MODIFIED)_(?i:AT|BY)") ) ) )
See the configuration XSD and programmatic code generation for more details.
import org.jooq.meta.jaxb.* configuration { generator { database { forcedTypes { forcedType { // Possible values for visibilityModifier // - DEFAULT : The default per language (Java: public, Kotlin, Scala: implicit public) // - NONE : Do not generate visibility modifiers // - PUBLIC : Generate explicit public modifiers (Java, Kotlin) // - INTERNAL : Generate explicit internal modifiers (Kotlin) // - PRIVATE : Generate explicit private modifiers (Java, Kotlin, Scala) visibilityModifier = VisibilityModifier.PRIVATE includeExpression = "(?i:CREATED|MODIFIED)_(?i:AT|BY)" } } } } }
See the configuration XSD and gradle code generation for more details.
configuration { generator { database { forcedTypes { forcedType { // Possible values for visibilityModifier // - DEFAULT : The default per language (Java: public, Kotlin, Scala: implicit public) // - NONE : Do not generate visibility modifiers // - PUBLIC : Generate explicit public modifiers (Java, Kotlin) // - INTERNAL : Generate explicit internal modifiers (Kotlin) // - PRIVATE : Generate explicit private modifiers (Java, Kotlin, Scala) visibilityModifier = "PRIVATE" includeExpression = "(?i:CREATED|MODIFIED)_(?i:AT|BY)" } } } } }
See the configuration XSD and gradle code generation for more details.
generationTool { generator { database { forcedTypes { forcedType { // Possible values for visibilityModifier // - DEFAULT : The default per language (Java: public, Kotlin, Scala: implicit public) // - NONE : Do not generate visibility modifiers // - PUBLIC : Generate explicit public modifiers (Java, Kotlin) // - INTERNAL : Generate explicit internal modifiers (Kotlin) // - PRIVATE : Generate explicit private modifiers (Java, Kotlin, Scala) visibilityModifier = "PRIVATE" includeExpression = "(?i:CREATED|MODIFIED)_(?i:AT|BY)" } } } } }
See the configuration XSD and gradle code generation for more details.
Such private columns can now no longer be referred by user queries explicitly, although they are still a part of the table, and can be projected when projecting all columns. Custom code sections in generated code can still access these columns, and so can inline converters.
It may make sense to combine this feature with client side computed columns, e.g. to compute a column A
based on a column B
, and then hide B
from user code to make sure users always use A
, instead.
Not all values make sense for all languages.
See also global visibility modifiers for further options.
Feedback
Do you have any feedback about this page? We'd love to hear it!