Data Tracking Configuration

broadleaf.tracking.pageable.page-request-default-max-page-size

The maximum page size for DefaultPageRequest. Be cautious when increasing this value, as setting it too high can cause issues with too many results being returned.

2000

broadleaf.tracking.pageable.narrow-pageable-argument-resolver-default-max-page-size

The maximum page size for NarrowPageableHandlerMethodArgumentResolver. Be cautious when increasing this value, as setting it too high can cause issues with too many results being returned.

2000

(since DataTracking 2.0.5) broadleaf.common.data.application.configuration.populate-audit-update-on-create

Should audit update fields be populated on create with the same value as create field

false

broadleaf.tracking.sandbox.purge.enabled

Whether purging of obsolete sandbox data is enabled.

true

broadleaf.tracking.sandbox.purge.obsolete-data-age-cutoff

This is the duration used to determine whether sandbox data is outdated. The current time (the time that the scheduled job is handled) minus this duration is the age cutoff that will be used. All sandbox-archived records whose last-updated audit timestamps are all older than this cutoff will be deleted.

60 days

broadleaf.data.tracking.jpa.purge-obsolete-sandbox-data.max-batch-size

The maximum number of main entities to purge in a single batch.

100

broadleaf.data.tracking.jpa.purge-obsolete-sandbox-data.max-number-of-batches

The maximum number of batches to process. This limit is useful to set an upper bound on each execution of the purge process. Typically, the expectation is for any remaining records to be deleted on the next execution of the purge process.

50

broadleaf.propagation.allow-hierarchy-propagation-handlers (since DataTracking 2.0.7)

If enabled, DefaultPropagationManager will allow the use of HierarchyPropagationHandler components. Whether any of the HierarchyPropagationHandler components are actually used in a particular request depends on whether any of them can handle it, but this toggle represents a top-level opt-in/opt-out flag to gate whether the hierarchical handlers are even an available option for propagation. By default, this is set to false for backward compatibility.

false

broadleaf.propagation.recursive-propagation-catalog-ids-processing-batch-size (since DataTracking 2.0.7)

When using the standard recursive propagation flow in DefaultPropagationManager, there may be a huge number of direct child catalogs found for any given catalog. Each of those may contain an override record that should be the target of propagation. We don’t want to load too many things in memory, or exceed query size limits with large 'IN' clauses. Batching becomes especially important due to the recursive nature of the propagation. For example, without any limits, if you have 10000 child catalogs, each with their own product override, you’ll have loaded 10000 child catalogs IDs as well as 10000 products at the first layer of recursion. Then, as you process each product, each one will enter this flow at the next level of recursion - it will load the next layer of catalog IDs and override entities, stacking on top of what we already have at the first layer. By setting a reasonable limit on how many entities are loaded at a time at each layer, we can place an upper bound on memory usage. Generally speaking, the default should suffice for most use cases.

500

broadleaf.propagation.default-propagation-handler.emit-persistence-message-on-applied-propagation (since DataTracking 2.0.7)

Whether a PERSISTENCE message should be emitted with the updated state of an entity after propagated changes from a parent record have been applied to it. Default is true. Prior to 2.0.7, PERSISTENCE messages were always enabled, which is why the default is set to true.

true