Learn T-SQL With Erik: Heap Table Problems with Updates and Deletes

Chapters

• *00:00:00* – Introduction
• *00:01:01* – SQL Server Specific Content
• *00:02:01* – Free Resources
• *00:03:11* – Upcoming SQL Day Poland
• *00:03:30* – Travel Notes
• *00:03:46* – Pass Summit in Seattle
• *00:04:06* – New Image Update
• *00:04:13* – April Fool’s Joke Video
• *00:04:23* – SQL Server Management Studio
• *00:05:04* – Heaps and Clustered Indexes
• *00:05:30* – Clustered Tables
• *00:05:52* – Load Elhepo Procedure
• *00:06:05* – Forwarded Records
• *00:06:28* – Updating Heap
• *00:07:00* – Forwarded Records After Update
• *00:08:30* – Forwarded Records in Table
• *00:09:01* – Rebuilding Table
• *00:10:53* – Deletions and Heaps
• *00:12:02* – Lob Columns and Heaps
• *00:14:18* – Deleting from Heap
• *00:16:51* – Heaps as Specialized Structures

Going Further

If this is the kind of SQL Server stuff you love learning about, you’ll love my training. Blog readers get 25% off the Everything Bundle — over 100 hours of performance tuning content. Need hands-on help? I offer consulting engagements from targeted investigations to ongoing retainers. Want a quick sanity check before committing to a full engagement? Schedule a call — no commitment required.

The post Learn T-SQL With Erik: Heap Table Problems with Updates and Deletes appeared first on Darling Data.

“Is ContosoParts.msix installed?” is a common – but misleading – question

The term install is not a formal concept in MSIX.

This may seem paradoxical for a deployment technology, but it makes perfect sense once you understand MSIX deployment’s core architecture.

Deployment Requests

A caller makes a deployment request to the deployment engine via the PackageManager API to perform some activity. This may involve adding a package to the system, removing one, or performing another management operation. Deployment requests include:

• the requested action
• the target package
• API parameters supplied by the caller
• contextual information about the requesting user (e.g., user ID and security context)

The system queues the request in the deployment engine’s memory for processing by the deployment pipeline.

The Deployment Pipeline

The deployment pipeline processes requests through an ordered set of steps. The pipeline may short-circuit or skip some steps, depending on the request and system state. At its core the processing consists of three primary stages:

• Index
• Stage
• Register

Index

Parse the incoming package’s metadata (for example, AppxManifest.xml) and store that information along with system metadata such as the intended installation path.

Stage

Create the package’s target installation location (also known as the package directory, or pkgdir).

Acquire the package payload and extract it into the pkgdir, and apply appropriate ACLs to secure the content.

Register

Associate the staged package with a specific user profile.

This may involve, among other actions:

• creating Start Menu entries
• registering file type associations
• configuring runtime data

Registering the package effectively makes it usable for that user.

Per-Machine vs Per-User

Indexing and Staging are per-machine activities. The system performs these once per machine.

Staged packages are stored and shared across all users on the system, with the pkgdir secured to allow Read and Execute access — but not Write access — to users.

Registering is a per-user activity.

This separation enables MSIX to alter the set of available packages for one user without affecting others. This isolation — and the controlled servicing it enables — is a cornerstone of MSIX’s design and is reflected in many platform behaviors and APIs.

So… Installing?

To make a package available for a user for the first time, a caller might invoke an Add API:

var packageUri = new Uri("C:\\Packages\\ContosoParts.msix");
var options = new AddPackageOptions();
var packageManager = new PackageManager();
var result = await packageManager.AddPackageByUriAsync(packageUri, options);
...

This sends an Add request to the deployment engine, which:

• Indexes the package
• Stages the package into a new pkgdir
• Registers it for the user

At no point did we technically “install” anything.

Even though we just installed the package

The post There is no Install – it’s ‘Stage’ and ‘Register’ appeared first on Inside MSIX.

Back in 2019, Dominick Baier, Duende Cofounder and Security subject-matter expert, wrote a prophetic post called "Two is the Magic Number", a riff on De La Soul's "Three is the Magic Number", arguing that you only needed two OAuth flows to cover every real-world scenario. At the time, it was a bold simplification. OAuth 2.0 had shipped with a sprawl of grant types: Implicit, Resource Owner Password Credentials, Authorization Code without PKCE, Client Credentials, and the ecosystem dutifully built tutorials for all of them. The result was confusion. Developers picked the wrong flow, shipped insecure apps, and blamed OAuth itself for being "too complicated."

Dominick was right, and the standards body agreed. OAuth 2.1 formally removed the footguns, mandated PKCE on every authorization code grant, and left us with a protocol that is dramatically simpler to learn and harder to misuse. If you're building on .NET 10 in 2026, this is the only article you need. Two flows cover almost everything. A third handles the edge case. Let's go.

Read more of this story at Slashdot.

In Kubernetes v1.36, Declarative Validation for Kubernetes native types has reached General Availability (GA).

For users, this means more reliable, predictable, and better-documented APIs. By moving to a declarative model, the project also unlocks the future ability to publish validation rules via OpenAPI and integrate with ecosystem tools like Kubebuilder. For contributors and ecosystem developers, this replaces thousands of lines of handwritten validation code with a unified, maintainable framework.

This post covers why this migration was necessary, how the declarative validation framework works, and what new capabilities come with this GA release.

The Motivation: Escaping the "Handwritten" Technical Debt

For years, the validation of Kubernetes native APIs relied almost entirely on handwritten Go code. If a field needed to be bounded by a minimum value, or if two fields needed to be mutually exclusive, developers had to write explicit Go functions to enforce those constraints.

As the Kubernetes API surface expanded, this approach led to several systemic issues:

1. Technical Debt: The project accumulated roughly 18,000 lines of boilerplate validation code. This code was difficult to maintain, error-prone, and required intense scrutiny during code reviews.
2. Inconsistency: Without a centralized framework, validation rules were sometimes applied inconsistently across different resources.
3. Opaque APIs: Handwritten validation logic was difficult to discover or analyze programmatically. This meant clients and tooling couldn't predictably know validation rules without consulting the source code or encountering errors at runtime.

The solution proposed by SIG API Machinery was Declarative Validation: using Interface Definition Language (IDL) tags (specifically +k8s: marker tags) directly within types.go files to define validation rules.

Enter validation-gen

At the core of the declarative validation feature is a new code generator called validation-gen. Just as Kubernetes uses generators for deep copies, conversions, and defaulting, validation-gen parses +k8s: tags and automatically generates the corresponding Go validation functions.

These generated functions are then registered seamlessly with the API scheme. The generator is designed as an extensible framework, allowing developers to plug in new "Validators" by describing the tags they parse and the Go logic they should produce.

A Comprehensive Suite of +k8s: Tags

The declarative validation framework introduces a comprehensive suite of marker tags that provide rich validation capabilities highly optimized for Go types. For a full list of supported tags, check out the official documentation. Here is a catalog of some of the most common tags you will now see in the Kubernetes codebase:

• Presence: +k8s:optional, +k8s:required
• Basic Constraints: +k8s:minimum=0, +k8s:maximum=100, +k8s:maxLength=16, +k8s:format=k8s-short-name
• Collections: +k8s:listType=map, +k8s:listMapKey=type
• Unions: +k8s:unionMember, +k8s:unionDiscriminator
• Immutability: +k8s:immutable, +k8s:update=[NoSet, NoModify, NoClear]

Example Usage:

type ReplicationControllerSpec struct {
 // +k8s:optional
 // +k8s:minimum=0
 Replicas *int32 `json:"replicas,omitempty"`
}

By placing these tags directly above the field definitions, the constraints are self-documenting and immediately visible to anyone reading the type definitions.

Advanced Capabilities: "Ambient Ratcheting"

One of the most substantial outcomes of this work is that validation ratcheting is now a standard, ambient part of the API. In the past, if we needed to tighten validation, we had to first add handwritten ratcheting code, wait a release, and then tighten the validation to avoid breaking existing objects.

With declarative validation, this safety mechanism is built-in. If a user updates an existing object, the validation framework compares the incoming object with the oldObject. If a specific field's value is semantically equivalent to its prior state (i.e., the user didn't change it), the new validation rule is bypassed. This "ambient ratcheting" means we can loosen or tighten validation immediately and in the least disruptive way possible.

Scaling API Reviews with kube-api-linter

Reaching GA required absolute confidence in the generated code, but our vision extends beyond just validation. Declarative validation is a key part of a comprehensive approach to making API review easier, more consistent, and highly scalable.

By moving validation rules out of opaque Go functions and into structured markers, we are empowering tools like kube-api-linter. This linter can now statically analyze API types and enforce API conventions automatically, significantly reducing the manual burden on SIG API Machinery reviewers and providing immediate feedback to contributors.

What's next?

With the release of Kubernetes v1.36, Declarative Validation graduates to General Availability (GA). As a stable feature, the associated DeclarativeValidation feature gate is now enabled by default. It has become the primary mechanism for adding new validation rules to Kubernetes native types.

Looking forward, the project is committed to adopting declarative validation even more extensively. This includes migrating the remaining legacy handwritten validation code for established APIs and requiring its use for all new APIs and new fields. This ongoing transition will continue to shrink the codebase's complexity while enhancing the consistency and reliability of the entire Kubernetes API surface.

Beyond the core migration, declarative validation also unlocks an exciting future for the broader ecosystem. Because validation rules are now defined as structured markers rather than opaque Go code, they can be parsed and reflected in the OpenAPI schemas published by the Kubernetes API server. This paves the way for tools like kubectl, client libraries, and IDEs to perform rich client-side validation before a request is ever sent to the cluster. The same declarative framework can also be consumed by ecosystem tools like Kubebuilder, enabling a more consistent developer experience for authors of Custom Resource Definitions (CRDs).

Getting involved

The migration to declarative validation is an ongoing effort. While the framework itself is GA, there is still work to be done migrating older APIs to the new declarative format.

If you are interested in contributing to the core of Kubernetes API Machinery, this is a fantastic place to start. Check out the validation-gen documentation, look for issues tagged with sig/api-machinery, and join the conversation in the #sig-api-machinery and #sig-api-machinery-dev-tools channels on Kubernetes Slack (for an invitation, visit https://slack.k8s.io/). You can also attend the SIG API Machinery meetings to get involved directly.

Acknowledgments

A huge thank you to everyone who helped bring this feature to GA:

• Tim Hockin
• Joe Betz
• Aaron Prindle
• Lalit Chauhan
• David Eads
• Darshan Murthy
• Jordan Liggitt
• Patrick Ohly
• Maciej Szulik
• Wojciech Tyczynski
• Joel Speed
• Bryce Palmer

And the many others across the Kubernetes community who contributed along the way.

Welcome to the declarative future of Kubernetes validation!

Why Copilot Spaces + Markdown repos work so well

When you ask Copilot generic questions (“How should we log errors?” “What’s our API versioning approach?”), the model will often respond with reasonable defaults. But reasonable defaults are not the same as your standards.

Copilot Spaces solve the context problem by allowing you to attach a curated set of sources (files, folders, repos, PRs/issues, uploads, free text) plus explicit instructions—so Copilot answers in the context of your team’s rules and artifacts. Spaces can be shared with your team and stay updated as the underlying GitHub content changes—so your “best practices coach” stays evergreen.

The architecture (high level)

Here’s the mental model:

Engineering Knowledge Base Repo: A dedicated repo containing your standards as Markdown (coding style, architecture decisions, security rules, testing conventions, examples, templates).

Copilot Space: “Engineering Standards Coach”: A Space that attaches the knowledge base repo (or key folders/files within it), optionally your main application repo(s), and a short set of “rules of engagement” (instructions).

In-repo reinforcement (optional but powerful): Custom instruction files (repo-wide + path-specific) and prompt files (slash commands) inside your production repos to standardize behavior and workflows.

Step 1 Create a Knowledge Base repo (Markdown-first)

Create a repo such as:

• engineering-knowledge-base
• platform-playbook
• org-standards

A practical starter structure:

engineering-knowledge-base/
  README.md
  standards/
    coding-style.md
    logging.md
    error-handling.md
    performance.md
  security/
    secure-coding.md
    secrets.md
    threat-modeling.md
  architecture/
    overview.md
    adr/
      0001-service-boundaries.md
      0002-api-versioning.md
  testing/
    unit-testing.md
    integration-testing.md
    contract-testing.md
  templates/
    pr-review-checklist.md
    api-design-checklist.md
    definition-of-done.md

Tip: Keep these docs opinionated, concrete, and example-heavy—Copilot works best when it can point to specific patterns rather than abstract principles.

Step 2 Create a Copilot Space and attach your sources

Create a space, name it, choose an owner (personal or organization), then add sources and instructions. Inside the Space, add two types of context: Instructions (how Copilot should behave) and Sources (your actual code and docs).

2.1 Instructions (how Copilot should behave in this Space)

Example instructions you can paste:

You are the Engineering Standards Coach for this organization.

Goals:
- Recommend solutions that follow our standards in the attached knowledge base.
- When proposing code, align with our logging, error-handling, security, and testing guidelines.
- When uncertain, ask for the missing repo context or point to the exact standard that applies.

Output format:
- Start with the standard(s) you are applying (with a link or filename reference).
- Then provide the recommended implementation.
- Include a lightweight checklist for reviewers.

2.2 Sources (your real “knowledge base”)

Attach:

• The knowledge base repo (or just the folders that matter)
• Your main code repo(s) (or select folders)
• PR checklist and Definition of Done templates
• Key architecture docs, runbooks, or troubleshooting guides

Step 3 (Optional) Add instruction files to your production repos

Spaces are excellent for curated context and team-wide “ask me anything about our standards.” But you can reinforce consistency directly inside each repo by adding custom instruction files.

3.1 Repo-wide instructions (.github/copilot-instructions.md)

Create: your-app-repo/.github/copilot-instructions.md

# Repository Copilot Instructions

## Tech stack
- Language: TypeScript (strict)
- Framework: Node.js + Express
- Testing: Jest
- Lint/format: ESLint + Prettier

## Engineering rules
- Use structured logging as defined in /docs/logging.md
- Never log secrets or raw tokens
- Prefer small, composable functions
- All new endpoints must include: input validation, authz checks, unit tests, and consistent error handling

## Build & test
- Install: npm ci
- Test: npm test
- Lint: npm run lint

3.2 Path-specific instructions (.github/instructions/*.instructions.md)

Create: your-app-repo/.github/instructions/security.instructions.md

---
applyTo: "**/*.ts"
---
# Security rules (TypeScript)

- Never introduce dynamic SQL construction; use parameterized queries only.
- Any new external HTTP call must enforce timeouts and retry policy.
- Any auth logic must include negative tests.

Step 4 (Optional) Turn your best practices into “slash commands” with prompt files

To standardize repeatable workflows like code review, test scaffolding, or endpoint scaffolding, create prompt files (slash commands) as .prompt.md files—commonly in .github/prompts/. Engineers invoke them manually in chat by typing /.

Create: your-app-repo/.github/prompts/standards-code-review.prompt.md

---
description: Review code against our org standards (security, perf, style, tests)
---

You are a senior engineer performing a standards-based review.

Use these checks:
1) Security: input validation, authz, secrets, injection risks
2) Reliability: error handling, retries/timeouts, edge cases
3) Observability: structured logs, metrics, tracing where relevant
4) Testing: required coverage, negative tests, naming conventions
5) Style: follow repository rules in .github/copilot-instructions.md

Output:
- Summary (2-3 lines)
- Issues (severity: BLOCKER/REQUIRED/SUGGESTION)
- Suggested patch snippets (only where confident)
- “Ready to merge?” verdict

Now any engineer can type /standards-code-review and get the same structured output every time, without rewriting the prompt.

How teams actually use this day-to-day

Recipe A  Onboarding a new engineer

Ask inside the Space: “Summarize our service architecture and coding conventions for onboarding. Link the key docs.”

Recipe B  Writing a feature with best-practice guardrails

Ask in the Space: “We’re adding endpoint X. Generate a plan that follows our API versioning ADR and error-handling standard.”

Recipe C  Enforcing review standards consistently

In the repo, run the prompt file: /standards-code-review.

Governance and best practices (what to do / what to avoid)

1. Keep Spaces purpose-built. Avoid dumping an entire org into one Space if your goal is consistent, grounded output.
2. Prefer linking the “golden source.” Keep standards in a single repo and update them via PR—treat it like code.
3. Make instructions short but strict. Detailed rules belong in your Markdown standards.
4. Avoid conflicting instruction files. If instructions contradict each other, results can be inconsistent.

References (official docs for further reading)

About GitHub Copilot Spaces: https://docs.github.com/en/copilot/concepts/context/spaces 

Creating GitHub Copilot Spaces: https://docs.github.com/en/copilot/how-tos/provide-context/use-copilot-spaces/create-copilot-spaces 

Adding custom instructions for GitHub Copilot: https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/add-custom-instructions 

Use custom instructions in VS Code: https://code.visualstudio.com/docs/copilot/customization/custom-instructions 

Use prompt files in VS Code: https://code.visualstudio.com/docs/copilot/customization/prompt-files 

Closing: the “best practices” flywheel

Once you implement this pattern, you get a virtuous cycle: teams encode standards as Markdown; Copilot Spaces ground answers in those standards; prompt files and instruction files standardize execution; and code reviews shift from style policing to design and correctness.