There is a particular kind of quiet that data tools are good at. A filter that silently dropped a condition. An empty result that looks like "no matches" but means "your question was mis-read." An undo that puts back a row that is almost, but not quite, the one you deleted. Nothing throws. Nothing logs. The screen draws a perfectly plausible answer to a question you didn't ask.
Elyra DataGrid has spent most of its life fighting that quiet, and 0.7.0 is the release where the fight becomes visible on the page. Here's why the grid is built the way it is, how the new release works, and what it looks like in practice.
Most data grids are front-end components. You hand them an array, they sort and filter it in the browser, and the server is a dumb pipe. That's fine until the table has ten million rows, or until a filter the browser applied is one the database would never have allowed.
DataGrid is server-driven by design. A grid is defined once, in PHP, as a GridDefinition: which columns exist, what type each one is, which are filterable, sortable, editable, which values a column may take. That definition is the allow-list, and everything — a sort, a filter, an edit, a pasted batch of 500 rows, a question typed in plain English — is compiled against it on the server before it touches SQL. The database does the work; the browser draws the result.
One definition drives three clients — Livewire + Flux UI, Vue 3 + Inertia, Svelte 5 + Inertia — over one protocol. The grid follows your app rather than the other way round. And because the server compiles every filter, it can do things a browser grid cannot: stream a million-row export without holding it in memory, run faceted counts on the real data, group and aggregate with the database's own engine.
The feature people remember is ask the grid. Type a question — revenue over 50k in region Nord — and a server-side model turns it into a filter. The trick that makes it safe is that the model is never allowed to write SQL. It is told the grid's own columns and operators, it answers with a filter tree, and that tree is re-validated against the allow-list and compiled exactly like a hand-built filter. A field the grid doesn't declare, an operator a type doesn't support — dropped. Never unsafe SQL.
Here's the problem 0.7.0 fixes: dropped used to mean silently dropped. The allow-list threw a condition away and the user got a grid answering a narrower question than they asked, with nothing on screen to say so. A perfectly plausible result. The quiet kind.
Now the same call comes with a report:
$result = $grid->interpret('revenue over 50k in region Nord, contains "urgent"');
$result->matched(); // false — something was left out
$result->dropped(); // [['field' => 'revenue', 'op' => 'contains', 'reason' => 'operator not allowed for number']]
All three clients render that under the filter:
We could not apply "contains" to revenue — it's a number.
The user knows exactly what the grid heard, and exactly what it didn't.
Deliberately, this is not a confidence score. It would have been easy to ask the model "how sure are you?" and render 92% confident. But a self-reported confidence isn't calibrated — it's a number that feels like information — and showing it invites the user to trust the filter more at exactly the moment they should check it. What was dropped is ground truth. That's the thing worth rendering.
Two more wrong answers from the same corner are gone. A question about a text column holding 00123 used to bind the integer 123 and match nothing — an empty grid, not an error, the worse failure. And a half-open between compiled to BETWEEN ? AND NULL, which also matched nothing. Values are coerced by the declared type now, and a half-open range is refused and reported.
Asking goes one direction: words → filter. 0.7.0 adds the reverse: filter → words.
$grid->explain();
// "Region is Nord and (revenue over 50 000 or status is Won), matching 'nordic'"
That sentence sits under the toolbar in all three clients (public bool $explain = false; turns it off in Livewire). The interesting decision is that it is not an LLM call, even though the other direction is. A filter tree is structured data; describing it is formatting, not inference. So the sentence is faithful by construction — a model asked to describe a filter can describe it wrongly, and the reader can't tell — it costs nothing, needs no API key, and is therefore on every grid rather than only where the assistant is switched on. Nested groups are bracketed, because A and (B or C) and A and B or C select different rows, and that difference is the whole point of writing it down.
When a question matches nothing, the grid now shows what it can be filtered on: every filterable column, its type, its declared values. That is the allow-list itself — free, and unable to invent a field. Asking the model to suggest a better question would be neither.
Editing in DataGrid is inline, in-cell, modal or slideover, with batch edits validated on the server. 0.7.0 adds a change event:
use Elyra\DataGrid\Server\Events\GridRowChanged;
Event::listen(GridRowChanged::class, function (GridRowChanged $event) {
AuditLog::record(
row: $event->key,
changes: $event->changes(), // only what actually differs
undo: $event->inverse(), // the mutation that would put it back — or null
);
});
Two details carry the design. The event covers only the columns the grid declares — a table's password hashes and tokens stay out of it, the same boundary the mutation response has respected since 0.5.0, when create and update stopped returning SELECT *. An audit trail cannot leak what the grid does not show.
And inverse() returns null for a delete, on purpose. Restoring the row would go through the write allow-list, which strips the non-editable columns — the key included — so the "restored" row would come back with a new id and missing data. An undo that quietly produces a different row is worse than one that admits it cannot be built. So it admits it.
Capturing the previous row costs one SELECT, so it happens only when something is listening; a 500-row paste shouldn't pay 500 extra reads for an event with no consumer. A listener that throws is not caught: inside the transactional batch it rolls the write back, which is the right coupling for an audit trail.
The changelog for 0.7.0 opens with a sentence you don't often see: the first release since 0.6.2 in which shipped library code actually changes. 0.6.0, 0.6.1 and 0.6.2 shipped byte-identical package content — tooling, CI and docs work that got a version number because that's what the process did. So there is a release policy now: tag only when something under packages/ has changed. A version history should say something.
The same release deletes an npm publishing setup that pointed at a registry that doesn't exist and never published anything. It was there for a while, looking like a distribution channel. Now the JS packages are marked private, and the one path that works — the clients ship inside the Composer package — is the only one described.
None of that is a feature. All of it is the reason the features above can be believed.
DataGrid is a Laravel package, licensed per project. Define a grid, point a client at it, and try the thing most grids can't do: ask it a question, and read what it says it left out.
If a grid that tells you what it heard sounds like the way it should always have worked — the docs at elyracode.com/docs/datagrid start with why, and the natural-language guide has the new report in it.
Ask it something. Then read the answer's footnote.