Broadleaf Microservices
  • v1.0.0-latest-prod

Catalog Release Notes for 2.2.1-GA

Tip
 The 2.x versions are Spring Boot 3 compatible.

Requirements

  • JDK 17 is required for Broadleaf release trains 2.0.0-GA, and beyond.

  • This version now requires DataTracking 2.0.3+

  • This version is required by SearchService 2.1.5+ documented in the 2.2.1 Search Release Notes

Important Updates

Notable Changes

Added support for generating Business Type Routes and Components for multiple base views

Important
 Also see changes made in Admin Metadata Services 2.1.4

Instead of being hardcoded as part of the BusinessType metadata, the BusinessTypeFields metadataMappings are now derived from a property: broadleaf.catalog.metadata.product-business-type-route-component-keys.

broadleaf:
  catalog:
    metadata:
      product-business-type-route-component-keys:
        - catalog:products:${typeKey}:create
        - catalog:products:${typeKey}:update

Fix Select Repository Methods Failing on Large Result Sets

The original issue: certain repository methods could produce very large result sets, which would internally break the narrowing and join flows and cause the operation to fail. For example, if an entity has been extended, then after the initial query against the base BLC table, Hibernate does an additional query against the extension table using an IN criteria containing each ID from the base result set. If the base result set is too large, then the IN clause may exceed query size limits imposed by DB platforms.

The repository methods identified as being susceptible to this problem have been given new custom implementations that collect the results in batches before returning to the caller.

The general pattern of changes is like so:

  • The affected repository method signature is migrated from the main *Repository interface into a parent Customized*Repository interface.

    • This is backwards compatible, as the customized repository interfaces are always parents of the main interfaces. Thus, the methods will still be available to components that are injecting the repository bean.

  • In the JpaCustomized*Repository class, the method is implemented in a way that gathers results in batches.

  • Configuration properties are introduced which allow clients to customize the internal batch sizes for each method implementation.

Here is a list of affected repositories and repository methods:

  • ProductTagRepository

  • PromotionalCategoryProductRepository

  • PromotionalProductRepository

  • CategoryProductRepository

  • CategoryAssetRepository

  • CategoryRepository

  • OptionTemplateRepository

    Note
    		 As there was no pre-existing CustomizedOptionTemplateRepository interface or implementation, it was newly introduced as part of this effort.

  • Implemented Business Type Characteristics Inheritance

    • Added field ancestors to BusinessType to store a list of other Business Types that this type can inherit attributes from. This field is only available on the projection domain and is set in the business logic.

      • If a Business Type’s productType key is not any of the DefaultProductType enums (meaning it is not one of the default product types that are included out-of-box), then it is pointing to another Business Type whose typeKey matches the productType key. This indicates that this Business Type can inherit certain attributes from its parent Business Type (also known as its ancestor), such as Characteristics.

      • When updating a Product whose Business Type has a parent Business Type, the Product is hydrated with all inherited characteristics from its ancestor Business Types. See BusinessTypeAncestryHydrationService to see how this hydration is performed.

Bug Fixes

Fix Select Repository Methods Failing on Large Result Sets

The original issue: certain repository methods could produce very large result sets, which would internally break the narrowing and join flows and cause the operation to fail. For example, if an entity has been extended, then after the initial query against the base BLC table, Hibernate does an additional query against the extension table using an IN criteria containing each ID from the base result set. If the base result set is too large, then the IN clause may exceed query size limits imposed by DB platforms.

The repository methods identified as being susceptible to this problem have been given new custom implementations that collect the results in batches before returning to the caller.

The general pattern of changes is like so:

  • The affected repository method signature is migrated from the main *Repository interface into a parent Customized*Repository interface.

    • This is backwards compatible, as the customized repository interfaces are always parents of the main interfaces. Thus, the methods will still be available to components that are injecting the repository bean.

  • In the JpaCustomized*Repository class, the method is implemented in a way that gathers results in batches.

  • Configuration properties are introduced which allow clients to customize the internal batch sizes for each method implementation.

Here is a list of affected repositories and repository methods:

Consolidated Product Additions and Changes

Note
 This change is important to fix issues with the Solr search narrowing.

  • The ConsolidatedProduct domain has been updated to contain a few new fields which are utilized in the Solr search process. These fields have been added to aid in narrowing of results. See the 2.1.5 Search Release Notes for the updates made on search.

    • creatingApplicationId

      • Contains the ID of the application which owns the Product, if it exists. This will be null when a Product is created at the Tenant level.

      • This value is designed to be the same as the value in Tracking.creatingApplicationId.

    • sandboxAwareCatalogOverrides

      • Contains Catalog override ids with additional Sandbox information encoded to aid with narrowing products that are both Sandbox and Catalog discriminated.

    • catalogAwareSandboxOverrides

      • Contains Sandbox override ids with additional Catalog information encoded to aid with narrowing products that are both Sandbox and Catalog discriminated.

  • Update DefaultConsolidatedProductPostProcessor and DefaultProductConsolidationService with changes to populate the above fields added onto ConsolidatedProduct.

    • The method signature of DefaultProductConsolidationService#createPostProcessor was updated as a part of this change, so clients who have overridden this method or are directly referencing it will need to update their references to match the new signature.

  • Update ProductConsolidationUtil to fix a bug where a null author could be passed or an incorrect author if a record contained changes from multiple authors.

  • Updated the Javadocs within ConsolidatedProduct and DefaultConsolidatedProductPostProcessor to more accurately and clearly describe some of the existing and new functionality.

Miscellaneous

  • Fixed an issue where after updating the maxConfigurableProductDepth property, any fetch information requests about a product that doesn’t have any addOns can lead to an error.

  • Bundle Item availability during Product consolidation for search indexing not really considering different sandbox versions for the consolidated products in question.

  • Fixed not indexing the priceWithDependentItems for Merchandising products.

  • Previously, users were able to change the Option Type of an Option Template even after the template had been saved. This could lead to inconsistencies and unexpected behavior. The application now disallows updates to the Option Type once an Option Template has been saved.

  • Fixed that a product is not visible on storefront when there is a difference in product’s category hierarchy in application level vs tenant

  • Make option template’s allowed values grid orderable with drag’n’drop, also make option template’s allowed values grid column displayOrder readonly