Blog
After an Elixir-packed summer to “sharpen the functional-programming saw” for the upcoming chapters of Phoenix Product Codex , I just released Chapter 8 on Leanpub !
In this one, we almost complete the modeling of the database with the new table for product variants (variants) and its Variant schema module with validation functions. All that’s left for completing the database ERD is a consequence of what we come up with in this chapter.
We explore three distinct approaches to modeling product variants and bundles (kits):
- a simple, battle-tested method,
- a wastefully redundant one, and
- one (that we pick) that ends up making use of our relational database.
An analysis of real-world scenarios and practical considerations informs our decision, such as “breaking bulk”, equipment breakage/shrinkage, minimum order quantities, and the need to track both component variants and bundles without losing hierarchical or pricing context.
With this approach, we make the need for the separate items table of the original ERD concept redundant, as we’ll be dynamically generating item codes from category and variant codes.
So, when we return to modeling bundles/kits in Chapter 10 after the upcoming Chapter 9’s side-quest, we’ll be using a kit_compositions table to define bundle recipes relationally. This will enable nested bundles (bundles including bundles that might themselves include bundles, etc.) while ensuring data integrity through custom Ecto changeset validations to prevent self-references and circular dependencies.
Beyond that, we extend the flexible-identifier feature to variants, and also come up with a way to avoid redundant information in the returned JSON with nested associations.
Chapter 9 (not released today yet) is a side-quest; we need to find a way to generate unique, typo-resistant variant codes within product categories that doesn’t succumb to combinatorial explosion–especially if we want to extend this to typo-resistance across all item codes and not just within a product category. We’ll be seeing how a brute-force approach of “rolling the dice” is slow, unreliable and doesn’t scale, and so we’ll be developing a solution with a Markov Chain.
Already in Chapter 8 we evaluate the performance of two different approaches of testing uniqueness with MapSet.intersect/2 and MapSet.member?/2 and see how these scale very differently.
Chapter 9 is progressing nicely, so expect to see an update within this week.
- The book is available as PDF and ePub on Leanpub
- Join the discussion on elixirforum.com