Use a hand-written entity class for this table's rows instead of a generated one -- the normal case as soon as the entity needs any behaviour of its own.
NOTE: this used to be typed `bool` while being assigned the column's NAME, which PHP silently coerced to
`true` -- so the name (the one thing callers need, to write back the id the database generated on INSERT)
was never actually retrievable. Verified directly.
Table.php:152function generateEntityClass(): stringNOTE: this used to be built from `$handler->getHref()`, i.e. the DSN -- which for SQLite is an absolute
filename, so the class was named after wherever the database happened to sit
(`sqlite__home_someone_project_data_sqlite_user`). That is machine-specific, and the name ends up in
serialized entity references, so it could not survive being moved between machines. It is now derived from
the table name plus a digest of its column SHAPE: stable everywhere, and still distinct for two same-named
tables whose columns differ.
Build a core Query against this table's collection.
function query(
?MMO\core\interfaces\iRepository $repo = null,
MMO\core\interfaces\iFilter|array|string $filter = [],
array|string $fields = [],
array|string $sort = [],
?int $limit = null,
?int $offset = null
): MMO\core\entities\QueryWARNING for whoever implements the repository side: a Query's field list is schema-driven, not
column-driven, so it asks for properties that are NOT columns of this table -- `status`, `uid` and
`metadata` come with every entity, and [`Query::listOnly()`](https://mcp.mmoframework.fr/documentation/mmo.core/php/entities/Query.md#query-listonly) additionally requests `label` and filters on
`status`. Whatever turns a Query into SQL must intersect its fields with [`getFields`](https://mcp.mmoframework.fr/documentation/mmo.pdo/php/helpers/Table.md#table-getfields) and decide what to
do with the rest, or the database will be asked for columns that do not exist.
every property PDOEntity already declares, mapped to whether it is an #[ArrayProperty] (i.e. part of the entity's data) rather than internal bookkeeping.
Use a hand-written entity class for this table's rows instead of a generated one -- the normal case as soon as the entity needs any behaviour of its own.
insert -- but note this is only meaningful when a row was actually INSERTED: after a conflict resolved as an update, the driver still reports the last id it ever generated