RUEN
Package · mui-data-grid

Upgrading to 3.0

Version 3.0 follows two changes in the framework — the root namespace was renamed and the data layer moved into its own package — and along the way fixes the one thing that was never portable: case-insensitive search hard-coded for PostgreSQL.

Upgrade in one step

No release works with both namespace layouts; they are mutually exclusive. Upgrade the framework and the adapter together.

1. Bump the constraint

bash
composer require flytachi/winter-mui-data-grid:^3.0

Composer pulls in flytachi/winter-kernel ^4.0 and flytachi/winter-ppa ^1.0. If your own composer.json pins the kernel at ^3.0, bump that too — otherwise the resolver refuses the install.

2. Rewrite the imports

Only framework types moved. Everything under Flytachi\Winter\MuiDataGrid\ and Flytachi\Winter\Cdo\Qb stayed where it was.

2.x 3.0 Now lives in
…\K2\Http\Request\Validation\{ListOf, Valid, In, Min, Max, Positive, …} Flytachi\Winter\Kernel\Http\Request\Validation\… winter-kernel
…\K2\Http\Request\Annotation\RequestJson Flytachi\Winter\Kernel\Http\Request\Annotation\RequestJson winter-kernel
…\K2\Http\Request\RequestException Flytachi\Winter\Kernel\Http\Request\RequestException winter-kernel
…\K2\Http\Response\ResponseEntity Flytachi\Winter\Kernel\Http\Response\ResponseEntity winter-kernel
…\K2\Route\Annotation\{RequestMapping, PostMapping, …} Flytachi\Winter\Kernel\Route\Annotation\… winter-kernel
…\K2\Ppa\Entity\RepositoryViewInterface Flytachi\Winter\Ppa\Entity\RepositoryViewInterface winter-ppa
…\K2\Unit\Pagination\Paginator Flytachi\Winter\Ppa\Pagination\Paginator winter-ppa

The last two rows are the trap: they are not a K2 → Kernel rename, those types left the kernel entirely. So in an automated rewrite they must come before the blanket rule:

bash
grep -rl 'Winter\\K2' src | xargs perl -pi -e '
s{Flytachi\\Winter\\K2\\Ppa\\Entity}{Flytachi\\Winter\\Ppa\\Entity}g;
s{Flytachi\\Winter\\K2\\Unit\\Pagination}{Flytachi\\Winter\\Ppa\\Pagination}g;
s{Flytachi\\Winter\\K2}{Flytachi\\Winter\\Kernel}g;
'

3. Three signatures changed

This only reaches you if you call the low-level pieces directly. The fluent interface — GridColumn::for(), GridSchema::make(), MuiGrid::wrap() — is unchanged.

2.x 3.0
MGOperator::toQb($column, $value) MGOperator::toQb($column, $value, TextMatch $mode)
GridColumn::resolveFilter($item) GridColumn::resolveFilter($item, TextMatch $mode)
GridSchema::buildWhere($model) GridSchema::buildWhere($model, ?TextMatch $mode = null)

filterUsing() resolvers keep working as written. The resolved mode is passed as a second argument, and PHP ignores arguments a user-defined callable doesn’t declare — so fn (MGFilterItem $i) => … is still valid. Declare the second parameter only if you need it:

php
->filterUsing(fn (MGFilterItem $i, TextMatch $m): ?Qb => /* … */)

4. contains is no longer PostgreSQL-only

Version 2.x emitted ILIKE for contains, notContains, startsWith and endsWith unconditionally. On MySQL and SQLite that is a syntax error, which means those four operators could not work there at all.

Version 3.0 resolves the spelling from the repository’s driver — the default TextMatch::Auto mode: ILIKE on PostgreSQL, LIKE on MySQL and SQLite, lower(col) LIKE lower(:v) elsewhere.

  • PostgreSQL projects — nothing changes, the emitted SQL is identical.
  • MySQL and SQLite projects — grids that were impossible now work. If you carried a filterUsing() workaround that respelled LIKE by hand, you can delete it; keeping it is harmless too, since an explicit resolver still wins.
  • Other databases (Oracle, a custom DbConfig) — you get the portable Lower. Pin ->textMatch(...) for anything else.

Compatibility

Package winter-kernel winter-ppa PHP
3.x ^4.0 ^1.0 ≥ 8.4
2.x ^3.0 (shipped inside the kernel) ≥ 8.4

Request and response payloads are byte-identical, so the frontend needs no changes: an endpoint written for 2.x differs only in its use lines.

Next steps