Issue with form helper trying to load schema from non-existing database table

[k-risc]

When not using dedicated table classes for the different entity types, and setting their "table" to the name of the shared table in the database, I get error messages about database tables not being found.

It seems the property _registryAlias, returned with getSource() is set to the name of the concrete entity class, not the base class.

Any code using that trying to load the corresponding database table, e.g. in the FormHelper/EntityContext, will throw that error, because it tries to load a non-existent database table.

My solution would be to define in the base entity class

    public function __construct(array $properties = [], array $options = [])
    {
        parent::__construct($properties, array_merge($options, [
            'source' => 'Compliancetasks',
        ]));
    }

This then sets the source in all special entity classes extending the base class correctly.

What I am wondering: is this really necessary and just not documented that this has to be done? Or is it not necessary and I am doing something wrong?

The StiBehavior, when building its type map, for each entry derives some $alias from the $entityName in order to check

• whether the special entity class exists
• in case a table happens to exist matching the special entity name, and that table is not the base table, and that table has its own entity class, being different from the currently added special entity, it throws an exception
• but then it also stores that alias in the config and uses it as the registry alias of special entity instances, so each instance has, as its source, something matching its class name, e.g. chefs, instead of the base name, e.g. cooks.

One solution would be to use the tableof the behavior config, which should be the base table, as the source of the special entity instances when creating them.

[ADmad]

How did you create the entity?

[k-risc]

I ran a query using the base table class. As mentioned above, this is about the situation where I do not use typed table classes (e.g. ChefsTable), but just the basic CooksTable, e.g.:

$chefsTable = TableRegistry::getTableLocator()->get('Chefs');
$results = $chefsTable->find(...);

The StiBehavior added to the ChefsTable kicks in, in beforeFind() it creates instances of the typed entity classes, and it sets the source to the 'alias' previously stored in the type map:

return new $entityClass($row->forCopy(), [
	'markNew' => $row->isNew(),
	'markClean' => true,
	'guard' => false,
	'source' => $this->_typeMap[$type]['alias'],
]);

But in addType(), that alias is defined as $alias = Inflector::pluralize($entityName);, so it is based on the entity name. For Chef, this will yield Chefs, and that is set as the source of the typed entity instance, which is then stored under _registryAlias.

CakePHP's FormHelper for example reads this when it want s to find out about the data type of a certain field of the entity, by anaylsing the database table schema. So it calls getSource() on the entity object and tries to load that as a table. If not dedicated table class exists, it builds a default table class object, and because the class name is Chefs, the table is set to chefs. So it tries to load a table chefs from the database, which does not exist.

If I define that table class myself and set its table to cooks, then it would work. Or I overwrite the source when creating an entity instance as above.

[ADmad]

But in addType(), that alias is defined as $alias = Inflector::pluralize($entityName);, so it is based on the entity name.

Below that there's a check whether the $className based on the $alias exists. So we could use that to switch the alias to that of the table to which the behavior is attached, if the classname doesn't exist. That would resolve your issue isn't it?

[k-risc]

Thanks very much for looking into this. Yes, that sounds like a viable option.

[ADmad]

Would you like to open a PR for this?

[k-risc]

I'll be happy to do so. I am not familiar with Github and creating PRs, so it might take a while. I cloned the repo and did the changes locally, but haven't managed to run the unit tests yet.

[k-risc]

Quick update, unit tests are running locally, but not passing. I am checking on this...

[k-risc]

Changing the 'alias' does not work. When creating new entities with ->newXXX(), the behavior call $this->_table($type) to get the correct table class. And in that function, the 'alias' is used to load the table class with that name from the registry. hanging the alias to "Cooks" will lead newChef() to still load and use the CooksTable to create the entity. The validation defined in the ChefsTable is not used. That is why testValidation() fails.

As far as I can see, we do need the typed table classes, because we then need to use $this->setTable('cooks');.