Db Mssql Laravel Package

Product Decisions This Supports

Upgrade planning and technical-debt budgeting. 2.0.0 is a major release with substantial breaking changes (QueryBuilder constructor signature, Quoter::getTableNameParts() parameter removal, Command::insertWithReturningPks() return type and rename to insertReturningPks(), exception type changes, removal of dot support in table names, removal of Schema::getCacheKey()/getCacheTag()). This is a scheduled upgrade workstream, not a drop-in patch — treat it as a scoped engineering task with a test-suite gate, not a routine composer update.

Platform baseline decision. PHP support is now 8.1 – 8.5. If the roadmap still includes PHP 8.0 targets, this upgrade is blocked until that's dropped; conversely, adopting 2.0.0 is the enabler for PHP 8.5 readiness and long-term security patching.

Feature parity across database drivers. The release closes several gaps versus sibling drivers: JSON column type support, enumeration column type support, column collation, case-sensitive LIKE, upsertReturning(), and DROP TABLE ... IF EXISTS / CASCADE. If the product supports multi-database deployments (SQL Server plus MySQL/PostgreSQL), this release reduces the "works on A, not on B" drift that generates support tickets and per-driver workarounds.

Performance and correctness of schema introspection. The new ColumnInterface / ColumnFactory / ColumnBuilder / ColumnDefinitionBuilder / SqlParser stack replaces string- and regex-based column handling with typed column classes and a real parser. PM-relevant outputs: faster type casting on every result set, more reliable column metadata (defaults, identity, collation, composite primary key ordering — Bug #360), and fewer silent type-mapping bugs in reporting/import features.

Use cases this unlocks or de-risks: SQL Server-backed admin panels and reporting dashboards that rely on typed result sets; ETL/import pipelines using JSON or enum columns; multi-tenant schema operations that need IF EXISTS/CASCADE semantics; upsert workflows needing returned primary keys (queue/idempotency patterns).

Build vs buy. This is a buy/adopt decision — the adapter is maintained upstream and moves in lockstep with yiisoft/db (now declaring a yiisoft/db-implementation virtual package). Building and maintaining equivalent SQL Server DDL/DML handling in-house is not a credible roadmap item; the relevant build-vs-buy question is only whether to stay on the 1.x line, fork, or move to a different abstraction layer.

When to Consider This Package

Adopt when:

• The product runs on SQL Server and lives in the Yii ecosystem (or a stack already using yiisoft/db), so this adapter is the natural persistence layer.
• You are on PHP 8.1+ and want a forward path to 8.3–8.5 without carrying an unsupported driver.
• You need DB features that 1.x handled poorly or not at all: JSON columns, enum columns, column collation, case-sensitive matching, upsertReturning, or schema migration operations with IF EXISTS/CASCADE.
• You are willing to absorb a one-time breaking upgrade and pin the yiisoft/db major version alongside it — these two packages must move together.

Look elsewhere when:

• You are on PHP 8.0 or older, or cannot upgrade within the current quarter. Stay on 1.x and plan the jump.
• The codebase relies on dotted table names, on hasLimit()/hasOffset() behavior, on the old Command::insertWithReturningPks() return contract, or on Schema::getCacheKey()/getCacheTag() for query caching. These are hard breaks requiring explicit remediation, not shims.
• You need a framework-agnostic DBAL (Doctrine DBAL, Laravel's Illuminate\Database) or a stack where Yii-specific interfaces are a liability — this adapter inherits Yii's type system and coupling by design.
• The team needs zero-surprise, non-major upgrades and has no capacity to run a full regression pass against SQL Server.
• You use MySQL-style unsigned columns in schema definitions against SQL Server — 2.0.0 now throws on "unsigned" usage rather than silently ignoring it, so any accidental carry-over will surface as runtime failures.

Migration guardrails to state up front: upgrade yiisoft/db and this package as a pair; run the integration suite against a real SQL Server instance, not mocks; explicitly test composite primary keys, default-value normalization on large values (PHP 8.5 warning fix), identity columns, and any LIKE queries whose expected casing semantics change.

How to Pitch It (Stakeholders)

For executives: We're being offered a major upgrade to our SQL Server data layer. It's a scheduled maintenance item with a defined cost: it requires PHP 8.1 minimum (so it also forces a decision on older runtime support), and it includes breaking API changes that need remediation and a regression test pass. In exchange we get a supported runtime through PHP 8.5, meaningfully faster and more correct type handling on every query result, and closure of feature gaps (JSON, enum, collation, upsert-returning) that currently cause per-database workarounds and support load. Recommendation: schedule it as a contained engineering task in the next cycle rather than letting it drift into an emergency upgrade when 1.x stops receiving security fixes.

For engineering: 2.0.0 replaces the ad-hoc column handling with a typed pipeline — ColumnInterface implementations per database type, ColumnFactory, ColumnBuilder, ColumnDefinitionBuilder, and a new SqlParser — backed by yiisoft/db 2.x. Expect the type-casting path to be both faster and stricter. The breaking surface is real and enumerable from the changelog: QueryBuilder constructor, Quoter::getTableNameParts(), insertReturningPks() rename and array|false return, InvalidArgumentException type change, dotted table names removed, getCacheKey()/getCacheTag() removed, plus expression namespace moves. Plan the work as: pin yiisoft/db 2.x, fix compile-time breaks first, then run integration tests on real SQL Server covering composite PKs, identity columns, defaults, and LIKE casing.

For product/QA: Behavior changes to verify rather than assume: LIKE is now case-sensitivity-controllable, composite primary key column ordering is corrected (previously wrong), identity columns are surfaced in result columns, and default values no longer emit PHP 8.5 warnings on large values. Unsigned column definitions now throw instead of degrading — that is intentional strictness, and any existing schema relying on it needs remediation before upgrade.