Package org.hibernate.boot

Interface MetadataBuilder

All Known Subinterfaces:
MetadataBuilderImplementor
All Known Implementing Classes:
AbstractDelegatingMetadataBuilderImplementor
public interface MetadataBuilder
Contract for specifying various overrides to be used in metamodel building.
Since:
5.0

  • Method Details

    • applyImplicitCatalogName

      MetadataBuilder applyImplicitCatalogName(String implicitCatalogName)
      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

      MetadataBuilder applyImplicitSchemaName(String implicitSchemaName)
      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

      MetadataBuilder applyImplicitNamingStrategy(ImplicitNamingStrategy namingStrategy)
      Specify the ImplicitNamingStrategy.

      Its default is defined by the "hibernate.implicit_naming_strategy" setting if using property-based configuration.

      Parameters:
      namingStrategy - The ImplicitNamingStrategy
      Returns:
      this, for method chaining
      See Also:

    • applyPhysicalNamingStrategy

      MetadataBuilder applyPhysicalNamingStrategy(PhysicalNamingStrategy namingStrategy)
      Specify the PhysicalNamingStrategy.

      Its default is defined by the "hibernate.physical_naming_strategy" setting if using property-based configuration.

      Parameters:
      namingStrategy - The PhysicalNamingStrategy
      Returns:
      this, for method chaining
      See Also:

    • applyColumnOrderingStrategy

      MetadataBuilder applyColumnOrderingStrategy(ColumnOrderingStrategy columnOrderingStrategy)
      Specify the ColumnOrderingStrategy.

      Its default is defined by the "hibernate.column_ordering_strategy" setting if using property-based configuration.

      Parameters:
      columnOrderingStrategy - The ColumnOrderingStrategy
      Returns:
      this, for method chaining
      See Also:

    • applySharedCacheMode

      MetadataBuilder applySharedCacheMode(SharedCacheMode cacheMode)
      Specify the second-level cache mode.

      Its default is defined by the javax.persistence.sharedCache.mode setting if using property-based configuration.

      Parameters:
      cacheMode - The cache mode.
      Returns:
      this, for method chaining
      See Also:

    • applyAccessType

      MetadataBuilder applyAccessType(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.

      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

      MetadataBuilder applyIndexView(org.jboss.jandex.IndexView jandexView)
      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

      MetadataBuilder applyScanOptions(ScanOptions scanOptions)
      Specify the options to be used in performing scanning.
      Parameters:
      scanOptions - The scan options.
      Returns:
      this, for method chaining
      See Also:

    • applyScanEnvironment

      MetadataBuilder applyScanEnvironment(ScanEnvironment scanEnvironment)
      Consider this temporary as discussed on ScanEnvironment
      Parameters:
      scanEnvironment - The environment for scanning
      Returns:
      this, for method chaining

    • applyScanner

      MetadataBuilder applyScanner(Scanner scanner)
      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

      MetadataBuilder applyArchiveDescriptorFactory(ArchiveDescriptorFactory factory)
      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

      MetadataBuilder applyImplicitListSemantics(CollectionClassification classification)

    • enableExplicitDiscriminatorsForJoinedSubclassSupport

      MetadataBuilder enableExplicitDiscriminatorsForJoinedSubclassSupport(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. 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

      MetadataBuilder enableImplicitDiscriminatorsForJoinedSubclassSupport(boolean enabled)
      Similarly to enableExplicitDiscriminatorsForJoinedSubclassSupport(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

      MetadataBuilder enableImplicitForcingOfDiscriminatorsInSelect(boolean supported)
      For entities which do not explicitly say, should we force discriminators into SQL selects? The (historical) default is false

      Its default is defined by the "hibernate.discriminator.force_in_select" setting if using property-based configuration.

      Parameters:
      supported - true indicates we will force the discriminator into the select; false indicates we will not.
      Returns:
      this, for method chaining
      See Also:

    • enableGlobalNationalizedCharacterDataSupport

      MetadataBuilder enableGlobalNationalizedCharacterDataSupport(boolean enabled)
      Should nationalized variants of character data be used in the database types? For example, should NVARCHAR be used instead of VARCHAR? NCLOB instead of CLOB?

      Its default is defined by the "hibernate.use_nationalized_character_data" setting if using property-based configuration.

      Parameters:
      enabled - true says to use nationalized variants; false says to use the non-nationalized variants.
      Returns:
      this, for method chaining
      See Also:

    • applyBasicType

      MetadataBuilder applyBasicType(BasicType<?> type)
      Specify an additional or overridden basic type mapping.
      Parameters:
      type - The type addition or override.
      Returns:
      this, for method chaining

    • applyBasicType

      MetadataBuilder applyBasicType(BasicType<?> type, String... keys)
      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

      MetadataBuilder applyBasicType(UserType<?> type, String... keys)
      Register an additional or overridden custom type mapping.
      Parameters:
      type - The custom type
      keys - The keys under which to register the custom type.
      Returns:
      this, for method chaining

    • applyTypes

      MetadataBuilder applyTypes(TypeContributor typeContributor)
      Apply an explicit TypeContributor (implicit application via ServiceLoader will still happen too)
      Parameters:
      typeContributor - The contributor to apply
      Returns:
      this, for method chaining

    • applyCacheRegionDefinition

      MetadataBuilder applyCacheRegionDefinition(CacheRegionDefinition cacheRegionDefinition)
      Apply a CacheRegionDefinition to be applied to an entity, collection, or query while building the Metadata object.
      Parameters:
      cacheRegionDefinition - The cache region definition to apply
      Returns:
      this, for method chaining

    • applyTempClassLoader

      MetadataBuilder applyTempClassLoader(ClassLoader tempClassLoader)
      Apply a ClassLoader for use while building the Metadata.

      Ideally we should avoid accessing ClassLoaders when perform 1st phase of bootstrap. This is a ClassLoader that can be used in cases where we absolutely must.

      In EE managed environments, this is the ClassLoader mandated by PersistenceUnitInfo.getNewTempClassLoader(). This ClassLoader is discarded by the container afterward, the idea being that the Class can still be enhanced in the application ClassLoader.

      In other environments, pass a ClassLoader that performs the same function, if desired.

      Parameters:
      tempClassLoader - ClassLoader for use while building the Metadata
      Returns:
      this, for method chaining

    • applySourceProcessOrdering

      @Deprecated(since="6", forRemoval=true) MetadataBuilder applySourceProcessOrdering(MetadataSourceType... sourceTypes)
      Deprecated, for removal: This API element is subject to removal in a future version.
      hbm.xml mappings are no longer supported, making this irrelevant
      Apply a specific ordering to the processing of sources.

      Unlike most of the methods of this interface (which deal with multiple values internally), this one replaces any source processing order that was already set.

      Its default is defined by the "hibernate.mapping.precedence" setting if using property-based configuration.

      Parameters:
      sourceTypes - The types, in the order they should be processed
      Returns:
      this for method chaining
      See Also:

    • applyFunctions

      MetadataBuilder applyFunctions(FunctionContributor functionContributor)
      Apply an explicit FunctionContributor (implicit application via ServiceLoader will still happen too)
      Parameters:
      functionContributor - The contributor to apply
      Returns:
      this, for method chaining

    • applySqlFunction

      MetadataBuilder applySqlFunction(String functionName, SqmFunctionDescriptor function)
      Contribute a SqmFunctionDescriptor to HQL.
      See Also:

    • applyAuxiliaryDatabaseObject

      MetadataBuilder applyAuxiliaryDatabaseObject(AuxiliaryDatabaseObject auxiliaryDatabaseObject)
      Contribute an AuxiliaryDatabaseObject.

    • applyAttributeConverter

      MetadataBuilder applyAttributeConverter(ConverterDescriptor descriptor)
      Adds an AttributeConverter by a ConverterDescriptor
      Parameters:
      descriptor - The descriptor
      Returns:
      this for 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:
      this for method chaining

    • applyAttributeConverter

      <O, R> MetadataBuilder applyAttributeConverter(Class<? extends AttributeConverter<O,R>> attributeConverterClass, boolean autoApply)
      Adds an AttributeConverter by Class, 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:
      this for method chaining

    • applyAttributeConverter

      <O, R> MetadataBuilder applyAttributeConverter(AttributeConverter<O,R> attributeConverter)
      Adds an AttributeConverter instance.
      Parameters:
      attributeConverter - The AttributeConverter instance.
      Returns:
      this for method chaining

    • applyAttributeConverter

      MetadataBuilder applyAttributeConverter(AttributeConverter<?,?> attributeConverter, boolean autoApply)
      Adds an AttributeConverter instance, 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:
      this for method chaining

    • build

      Metadata build()
      Actually build the metamodel
      Returns:
      The built metadata.