Interface MetadataBuilder
- All Known Subinterfaces:
MetadataBuilderImplementor
- All Known Implementing Classes:
AbstractDelegatingMetadataBuilderImplementor,MetadataBuilderImpl
- Since:
- 5.0
-
Method Summary
Modifier and TypeMethodDescriptionapplyAccessType(AccessType accessType) Specify the second-level access-type to be used by default for entities and collections that define second-level caching, but do not specify a granular access-type.Specify a particular ArchiveDescriptorFactory instance to use in scanning.applyAttributeConverter(AttributeConverter<?, ?> attributeConverter, boolean autoApply) Adds anAttributeConverterinstance, explicitly indicating whether to auto-apply it.<O,R> MetadataBuilder applyAttributeConverter(AttributeConverter<O, R> attributeConverter) Adds an AttributeConverter instance.<O,R> MetadataBuilder applyAttributeConverter(Class<? extends AttributeConverter<O, R>> attributeConverterClass) Adds an AttributeConverter by its Class.<O,R> MetadataBuilder applyAttributeConverter(Class<? extends AttributeConverter<O, R>> attributeConverterClass, boolean autoApply) Adds anAttributeConverterbyClass, explicitly indicating whether to auto-apply it.applyAttributeConverter(ConverterDescriptor<?, ?> descriptor) Adds an AttributeConverter by aConverterDescriptorapplyAuxiliaryDatabaseObject(AuxiliaryDatabaseObject auxiliaryDatabaseObject) Contribute anAuxiliaryDatabaseObject.applyBasicType(BasicType<?> type) Specify an additional or overridden basic type mapping.applyBasicType(BasicType<?> type, String... keys) Specify an additional or overridden basic type mapping supplying specific registration keys.applyBasicType(UserType<?> type, String... keys) Register an additional or overridden custom type mapping.applyCacheRegionDefinition(CacheRegionDefinition cacheRegionDefinition) Apply aCacheRegionDefinitionto be applied to an entity, collection, or query while building theMetadataobject.applyColumnOrderingStrategy(ColumnOrderingStrategy columnOrderingStrategy) Specify theColumnOrderingStrategy.applyFunctions(FunctionContributor functionContributor) Apply an explicitFunctionContributor(implicit application viaServiceLoaderwill still happen too)applyImplicitCatalogName(String implicitCatalogName) Specify the implicit catalog name to apply to any unqualified database names.applyImplicitListSemantics(CollectionClassification classification) applyImplicitNamingStrategy(ImplicitNamingStrategy namingStrategy) Specify theImplicitNamingStrategy.applyImplicitSchemaName(String implicitSchemaName) Specify the implicit schema name to apply to any unqualified database names.applyIndexView(Object jandexView) Deprecated.applyPhysicalNamingStrategy(PhysicalNamingStrategy namingStrategy) Specify thePhysicalNamingStrategy.applyScanEnvironment(ScanEnvironment scanEnvironment) Consider this temporary as discussed onScanEnvironmentapplyScanner(Scanner scanner) Specify a particular Scanner instance to use.applyScanOptions(ScanOptions scanOptions) Specify the options to be used in performing scanning.applySharedCacheMode(SharedCacheMode cacheMode) Specify the second-level cache mode.applySqlFunction(String functionName, SqmFunctionDescriptor function) Contribute aSqmFunctionDescriptorto HQL.applyTempClassLoader(ClassLoader tempClassLoader) Apply aClassLoaderfor use while building theMetadata.applyTypes(TypeContributor typeContributor) Apply an explicitTypeContributor(implicit application viaServiceLoaderwill still happen too)build()Actually build the metamodelenableExplicitDiscriminatorsForJoinedSubclassSupport(boolean enabled) Should we process or ignore explicitly defined discriminators in the case of joined subclasses? The legacy behavior of Hibernate was to ignore the discriminator annotations because Hibernate (unlike some providers) does not need discriminators to determine the concrete type when it comes to joined inheritance.enableGlobalNationalizedCharacterDataSupport(boolean enabled) Should nationalized variants of character data be used in the database types? For example, shouldNVARCHARbe used instead ofVARCHAR?NCLOBinstead ofCLOB?enableImplicitDiscriminatorsForJoinedSubclassSupport(boolean enabled) Similarly toenableExplicitDiscriminatorsForJoinedSubclassSupport(boolean), but here how should we treat joined inheritance when there is no explicitly defined discriminator annotations? If enabled, we will handle joined inheritance with no explicit discriminator annotations by implicitly creating one (following the JPA implicit naming rules).enableImplicitForcingOfDiscriminatorsInSelect(boolean supported) For entities which do not explicitly say, should we force discriminators into SQL selects? The (historical) default isfalse.
-
Method Details
-
applyImplicitCatalogName
Specify the implicit catalog name to apply to any unqualified database names.Its default is defined by the "hibernate.default_catalog" setting if using property-based configuration.
- Parameters:
implicitCatalogName- The implicit catalog name- Returns:
this, for method chaining- See Also:
-
applyImplicitSchemaName
Specify the implicit schema name to apply to any unqualified database names.Its default is defined by the "hibernate.default_schema" setting if using property-based configuration.
- Parameters:
implicitSchemaName- The implicit schema name- Returns:
this, for method chaining- See Also:
-
applyImplicitNamingStrategy
Specify theImplicitNamingStrategy.Its default is defined by the "hibernate.implicit_naming_strategy" setting if using property-based configuration.
- Parameters:
namingStrategy- TheImplicitNamingStrategy- Returns:
this, for method chaining- See Also:
-
applyPhysicalNamingStrategy
Specify thePhysicalNamingStrategy.Its default is defined by the "hibernate.physical_naming_strategy" setting if using property-based configuration.
- Parameters:
namingStrategy- ThePhysicalNamingStrategy- Returns:
this, for method chaining- See Also:
-
applyColumnOrderingStrategy
Specify theColumnOrderingStrategy.Its default is defined by the "hibernate.column_ordering_strategy" setting if using property-based configuration.
- Parameters:
columnOrderingStrategy- TheColumnOrderingStrategy- Returns:
this, for method chaining- See Also:
-
applyAccessType
Specify the second-level access-type to be used by default for entities and collections that define second-level caching, but do not specify a granular access-type.Its default is defined by the "hibernate.cache.default_cache_concurrency_strategy" setting if using property-based configuration.
- Parameters:
accessType- The access-type to use as default.- Returns:
this, for method chaining- See Also:
-
applyIndexView
Deprecated.Set thehibernate-modelssettinghibernate.models.jandex.indexinstead. This method has no effect.Allows specifying a specific Jandex index to use for reading annotation information.It's important to understand that if a Jandex index is passed in, it is expected that this Jandex index already contains all entries for all classes. No additional indexing will be done in this case.
- Parameters:
jandexView- The Jandex index to use.- Returns:
this, for method chaining- API Note:
- Here for future expansion. At the moment the passed Jandex index is not used.
-
applyScanOptions
Specify the options to be used in performing scanning.- Parameters:
scanOptions- The scan options.- Returns:
this, for method chaining- See Also:
-
applyScanEnvironment
Consider this temporary as discussed onScanEnvironment- Parameters:
scanEnvironment- The environment for scanning- Returns:
this, for method chaining
-
applyScanner
Specify a particular Scanner instance to use.Its default is defined by the "hibernate.archive.scanner" setting if using property-based configuration.
- Parameters:
scanner- The scanner to use.- Returns:
this, for method chaining- See Also:
-
applyArchiveDescriptorFactory
Specify a particular ArchiveDescriptorFactory instance to use in scanning.Its default is defined by the "hibernate.archive.interpreter" setting if using property-based configuration.
- Parameters:
factory- The ArchiveDescriptorFactory to use.- Returns:
this, for method chaining- See Also:
-
applyImplicitListSemantics
-
enableExplicitDiscriminatorsForJoinedSubclassSupport
Should we process or ignore explicitly defined discriminators in the case of joined subclasses? The legacy behavior of Hibernate was to ignore the discriminator annotations because Hibernate (unlike some providers) does not need discriminators to determine the concrete type when it comes to joined inheritance. However, for portability reasons we do now allow using explicit discriminators along with joined inheritance. It is configurable though to support legacy apps.Its default is defined by the "hibernate.discriminator.ignore_explicit_for_joined" setting if using property-based configuration.
- Parameters:
enabled- Should processing (not ignoring) explicit discriminators be enabled?- Returns:
this, for method chaining- See Also:
-
enableImplicitDiscriminatorsForJoinedSubclassSupport
Similarly toenableExplicitDiscriminatorsForJoinedSubclassSupport(boolean), but here how should we treat joined inheritance when there is no explicitly defined discriminator annotations? If enabled, we will handle joined inheritance with no explicit discriminator annotations by implicitly creating one (following the JPA implicit naming rules).Again the premise here is JPA portability, bearing in mind that some JPA provider need these discriminators.
Its default is defined by the "hibernate.discriminator.implicit_for_joined" setting if using property-based configuration.
- Parameters:
enabled- Should we implicitly create discriminator for joined inheritance if one is not explicitly mentioned?- Returns:
this, for method chaining- See Also:
-
enableImplicitForcingOfDiscriminatorsInSelect
For entities which do not explicitly say, should we force discriminators into SQL selects? The (historical) default isfalse.Its default is defined by the "hibernate.discriminator.force_in_select" setting if using property-based configuration.
- Parameters:
supported-trueindicates we will force the discriminator into the select;falseindicates we will not.- Returns:
this, for method chaining- See Also:
-
enableGlobalNationalizedCharacterDataSupport
Should nationalized variants of character data be used in the database types? For example, shouldNVARCHARbe used instead ofVARCHAR?NCLOBinstead ofCLOB?Its default is defined by the "hibernate.use_nationalized_character_data" setting if using property-based configuration.
- Parameters:
enabled-truesays to use nationalized variants;falsesays to use the non-nationalized variants.- Returns:
this, for method chaining- See Also:
-
applyBasicType
Specify an additional or overridden basic type mapping.- Parameters:
type- The type addition or override.- Returns:
this, for method chaining
-
applyBasicType
Specify an additional or overridden basic type mapping supplying specific registration keys.- Parameters:
type- The type addition or override.keys- The keys under which to register the basic type.- Returns:
this, for method chaining
-
applyBasicType
Register an additional or overridden custom type mapping.- Parameters:
type- The custom typekeys- The keys under which to register the custom type.- Returns:
this, for method chaining
-
applyTypes
Apply an explicitTypeContributor(implicit application viaServiceLoaderwill still happen too)- Parameters:
typeContributor- The contributor to apply- Returns:
this, for method chaining
-
applyCacheRegionDefinition
Apply aCacheRegionDefinitionto be applied to an entity, collection, or query while building theMetadataobject.- Parameters:
cacheRegionDefinition- The cache region definition to apply- Returns:
this, for method chaining
-
applyTempClassLoader
Apply aClassLoaderfor use while building theMetadata.Ideally we should avoid accessing
ClassLoaders when perform 1st phase of bootstrap. This is aClassLoaderthat can be used in cases where we absolutely must.In EE managed environments, this is the
ClassLoadermandated byPersistenceUnitInfo.getNewTempClassLoader(). ThisClassLoaderis discarded by the container afterward, the idea being that theClasscan still be enhanced in the applicationClassLoader.In other environments, pass a
ClassLoaderthat performs the same function, if desired.- Parameters:
tempClassLoader-ClassLoaderfor use while building theMetadata- Returns:
this, for method chaining
-
applyFunctions
Apply an explicitFunctionContributor(implicit application viaServiceLoaderwill still happen too)- Parameters:
functionContributor- The contributor to apply- Returns:
this, for method chaining
-
applySqlFunction
Contribute aSqmFunctionDescriptorto HQL.- See Also:
-
applyAuxiliaryDatabaseObject
Contribute anAuxiliaryDatabaseObject. -
applyAttributeConverter
Adds an AttributeConverter by aConverterDescriptor- Parameters:
descriptor- The descriptor- Returns:
thisfor method chaining
-
applyAttributeConverter
<O,R> MetadataBuilder applyAttributeConverter(Class<? extends AttributeConverter<O, R>> attributeConverterClass) Adds an AttributeConverter by its Class.- Parameters:
attributeConverterClass- The AttributeConverter class.- Returns:
thisfor method chaining
-
applyAttributeConverter
<O,R> MetadataBuilder applyAttributeConverter(Class<? extends AttributeConverter<O, R>> attributeConverterClass, boolean autoApply) Adds anAttributeConverterbyClass, explicitly indicating whether to auto-apply it.- Parameters:
attributeConverterClass- The AttributeConverter class.autoApply- Should the AttributeConverter be auto applied to property types as specified by its "entity attribute" parameterized type?- Returns:
thisfor method chaining
-
applyAttributeConverter
Adds an AttributeConverter instance.- Parameters:
attributeConverter- The AttributeConverter instance.- Returns:
thisfor method chaining
-
applyAttributeConverter
MetadataBuilder applyAttributeConverter(AttributeConverter<?, ?> attributeConverter, boolean autoApply) Adds anAttributeConverterinstance, explicitly indicating whether to auto-apply it.- Parameters:
attributeConverter- The AttributeConverter instance.autoApply- Should the AttributeConverter be auto applied to property types as specified by its "entity attribute" parameterized type?- Returns:
thisfor method chaining
-
build
Metadata build()Actually build the metamodel- Returns:
- The built metadata.
-
hibernate-modelssettinghibernate.models.jandex.indexinstead.