Newest first, grouped by year. Search or filter by topic.
One Postgres database, one schema per module, and entity configurations that are all empty bodies - what ModularMonolith's data layer declares about future service boundaries, and what its migrations quietly gave away.
From an inverted foundation to the version I'd deploy, KC Star evolved through ten explicit releases in the open. The retrospective on all of it - what versioning a schema publicly taught me about drift, variants, bugs as motivations, and simplicity as the real destination.
KC Star's wishlist folder holds four future engines - a multi-engine measures platform, multi-tenancy, predictive monitoring, and automated maintenance - all marked research phase, one with 500 lines of not-ready reference SQL. An honest look at the roadmap, and which one I'd build first.
V9 cached yes/no permission answers and inherited a revocation-staleness hazard. V9 Simplified caches finished calculation results instead - keyed on the employee's permission list, so a permission change changes the key and the stale entry is simply never hit. A better choice about what to cache.
KC Star V9 Simplified puts the permission check inside the measure calculation itself - a HasPermission call in the CASE that computes each aggregate. Read-time filtering, column masking, and an access level the view derives on the fly. The whole model, inlined.
KC Star V9 Simplified's schema is four permission tables and five seeded personas - full access, online-only, store-only, delivery-and-quotes, commission-only. GetFilteredSalesData takes an employee and returns exactly their slice. Permissions you can read in one table.
After nine versions of accumulating ambition, KC Star V9 Simplified does the rarest thing - it takes features away. No permission groups, no group cache, just direct permission lists. The README recommends starting here. Kicking off the series on the version I would actually deploy.
KC Star V9 checks permissions on every calculation, and checking is expensive. So it caches the yes/no answers in a PermissionCache table with a one-hour TTL and an upsert on every miss. Here is how it works, the claimed 95 percent hit rate, and the real cost of caching authorization.
When KC Star V9 denies a measure, it returns NULL, not zero - and the difference matters enormously once those values flow into aggregates. Here is the semantics of denial, the PermissionContext that records it, and why a redacted zero would quietly corrupt every total downstream.
Fusing per-employee permissions with per-change recalculation multiplies work by headcount. KC Star V9 ships both the naive per-employee implementation and an optimised per-permission-group one that collapses a thousand employees into seven groups. The most important design call in the version.
KC Star V9 fuses V8's intelligent recalculation with V6's permission-aware calculations - and folds the employee and their permissions into the very hash that decides what to recompute. Kicking off the series where two engines meet in one version, and complexity meets its reckoning.
KC Star V8's row-level trigger is genuinely selective. Its batch path, despite the name, loops every calculation-affecting dimension and recomputes most measures anyway. An honest audit of where the selectivity holds, where it doesn't, and a measure that zeroes itself out.
Switching KC Star from always-rebuild to selective recalculation means dropping V7's triggers and installing V8's without losing data. Unlike V7's chaotic refactor, this migration ships a real verification function - and one landmine where dimension ids mean different things.
KC Star V8's intelligence lives in one table - MeasureDimensionDependency - mapping which measures each dimension drives, with a DIRECT/INDIRECT/AGGREGATION type and an impact weight. Here is how the map is built, seeded and generated, and the priority formula that reads it.
The most satisfying demonstration of KC Star V8 is an UPDATE that does no work. Change PaymentMethod, a dimension nothing depends on, and the selective trigger recalculates zero measures. Here is the trigger that pulls it off - and a tautological bug sitting right beside it.
Every version through V7 rebuilt all the measures when a dimension changed. KC Star V8 recalculates only the ones that actually depend on what moved - dependency analysis, selective recalculation, and claimed 60 to 80 percent less work. Kicking off the intelligent recalculation series.
A pile of subsystems isn't an operable system until you can run it. KC Star's docs distil into a runbook - daily health checks, weekly index hygiene, monthly reindex and security review, PostgreSQL tuning, backups, and one consistency check that catches a whole class of corruption.
KC Star V7 ships two overlapping ways to partition and age out cold data - a static backup-partitioning subsystem and a dynamic one - both monthly range partitions on CreatedDate, both gated on one flag. The honest read on why a feature ended up implemented twice.
Refactoring KC Star V6's monolith into V7's subfolders broke the schema - so badly it took two passes of fix scripts to repair. Missing columns, duplicate triggers, a trigger literally named _Corrected, and a live test INSERT embedded in a migration. What the scars teach.
KC Star V7 scores its own health from queue depth, processing time and success rate, then maps that score to a batch cadence - from 30 seconds when healthy down to emergency mode when critical - and writes the decision back into its own settings. Clever, and honestly limited.
In KC Star V7 every batch run gets a generated id, a log row, a processed count and a time budget it must finish inside. Here is the orchestrator that ties it together, the per-batch exception isolation - and a variable-shadows-column bug I shipped in the middle of it.
KC Star V7 ships a six-table feature-flag system so you can turn capabilities on and retune settings without a deploy. Here is the normalized flag model, the twenty-one seeded flags, and the honest gap between what the changelog documents and what the code ships.
The per-row triggers that ran KC Star for six versions stop scaling at high volume. V7 turns them off and moves fact generation into an explicit batch pipeline. Kicking off the ultra-scale series - batch processing, feature flags, automated monitoring.
Two fix scripts in KC Star repair a V6 database where dimensions were hand-seeded but the fact-generation half of the pipeline never ran. A war story about half-run pipelines, the DO-block backfills that rescue them, and what a MANUAL_SETUP batch id confesses.
The KC Star V6 changelog documents an entire RBAC system - tables, functions, triggers, password columns - that appears nowhere in the actual SQL. Here is how I found the drift, why it happened, and why I treat the folder code as ground truth and the changelog as fiction.
