Transition Backup in YoPlanning: A Technical Analysis
Transitional backup in YoPlanning is designed to securely and granularly manage product updates and their impacts on associated sessions. This article focuses on the technical aspects to explain how this mechanism works in depth and why some data may differ across sessions.
Technical Architecture: How does it work?
Initial Data State When a product is created, its basic properties (name, description, price, etc.) are saved as an initial state in the database. Each session created from this product inherits this initial state.
Identification of dependent sessions When a product is modified, the system identifies all future sessions associated with that product. This includes:
Sessions having data strictly identical to the initial state of the product.
Sessions that have been customized through manual edits.
Comparison with the initial state Before applying a modification, Yoplanning compares the properties of the existing sessions with the initial state of the product:
If a session's properties still match the initial state, it is eligible for automatic update.
If any properties have been manually changed (e.g. an adjusted rate or a custom name), the session is excluded from the update to preserve those customizations.
Conditional Update Changes are applied only to eligible sessions. Others remain unchanged, ensuring that any specific customizations are not overwritten.
Transitional Backup During the update phase, the system uses a buffer mechanism:
Changes are first applied in a temporary area.
Once validated, they are transferred to active data. This process guarantees total integrity in the event of an error or interruption.
Why data may differ between sessions?
Common scenarios
Manually customized session If a user edits a session (e.g. changing the price or name), that customization overrides global product changes. This can make a session appear as if it "was not updated", when in fact it was deliberately excluded from the update to preserve customizations.
Partial product dependency Some sessions may not depend on all product properties. For example, a session might inherit the price but not the description. These partial dependencies explain why only some properties are updated.
Inconsistencies related to intermediate states During a transition, if an update is canceled or interrupted, some sessions may remain in an intermediate state. However, thanks to the transition save, these cases are rare and can be corrected by validating the transition again.
Diagnosis and resolution for customers
Case: Data appears to be incorrect in a session
Verifying Customizations: Confirm if the session has been manually modified by the customer.
Compare with initial state: Check if the current data matches the initial state or if it was inherited from a previous modification.
Case: Session was not updated
Eligibility Criteria Check: Identify if the session was excluded due to customizations.
Rerun Transition: Propose a manual or automated update to reapply global changes.
Conclusion
Transition backup in Yoplanning is a robust and scalable solution for managing product and session updates. It offers a balance between automation and customization, ensuring consistency while respecting user-specific changes. A good understanding of this mechanism is essential to answer customer questions and to leverage AI models in session management.
Last updated
