Question: Where is the best place to convert php values to database values?

[atlasphp]

Question: Where is the best place to convert php values to database values?

[fadoe]

@pmjones I played around and Atlas is a very good ORM. Not so bloated like doctrine. Thank you for this great work!
I think you should not remove the strict validation. Programs should validate the input/output.

Thanks again. I close this question.

[sunkan]

Hi

Have you had a look at https://github.com/atlasphp/Atlas.Orm/blob/2.x/docs/events.md

You could use the table events to turn the data to binary before update/Insert and then on select turn them back into string

[pmjones]

@fadoe does @sunkan's answer help you out?

[fadoe]

I test it with

class StationTableEvents extends TableEvents
{
    public function modifySelectedRow(TableInterface $table, RowInterface $row): void
    {
        $id = $row->id;

        $value = $this->convertToPHPValue($id);
        $row->id = $value;
    }

    private function convertToPHPValue($value): ?StationId
    {
        return $value ? StationId::fromString(Uuid::fromBytes($value)->toString()) : null;
    }

    private function convertToDatabaseValue($value): ?string
    {
        return $value instanceof StationId ? Uuid::fromString((string) $value)->getBytes() : null;
    }
}

But now i get this exception trace:

Exception trace:
 Atlas\Orm\Exception::invalidType() at /home/falk/Projekte/Applications/playlistgrabber/vendor/atlas/orm/src/Table/Row.php:323
 Atlas\Orm\Table\Row->assertValid() at /home/falk/Projekte/Applications/playlistgrabber/vendor/atlas/orm/src/Table/Row.php:297
 Atlas\Orm\Table\Row->modify() at /home/falk/Projekte/Applications/playlistgrabber/vendor/atlas/orm/src/Table/Row.php:122
 Atlas\Orm\Table\Row->__set() at /home/falk/Projekte/Applications/playlistgrabber/src/PlaylistGrabber/src/Infrastructure/Persistence/AtlasOrm/Station/StationTableEvents.php:25
 FaDoe\PlaylistGrabber\Infrastructure\Persistence\AtlasOrm\Station\StationTableEvents->modifySelectedRow() at /home/falk/Projekte/Applications/playlistgrabber/vendor/atlas/orm/src/Table/AbstractTable.php:544
 Atlas\Orm\Table\AbstractTable->getSelectedRow() at /home/falk/Projekte/Applications/playlistgrabber/vendor/atlas/orm/src/Table/TableSelect.php:330
 Atlas\Orm\Table\TableSelect->fetchRows() at n/a:n/a
 call_user_func_array() at /home/falk/Projekte/Applications/playlistgrabber/vendor/atlas/orm/src/Mapper/MapperSelect.php:127
 Atlas\Orm\Mapper\MapperSelect->__call() at /home/falk/Projekte/Applications/playlistgrabber/vendor/atlas/orm/src/Mapper/MapperSelect.php:263
 Atlas\Orm\Mapper\MapperSelect->fetchRecords() at /home/falk/Projekte/Applications/playlistgrabber/src/PlaylistGrabber/src/Infrastructure/Station/Repository/AtlasOrmStationRepository.php:42
...

So I think the best place to do this cast is in the repository after fetching the data. Or to write a entity that can handle the binary version for the ORM and the ValueObject version for the application.

[pmjones]

@fadoe Ah so! Yes, casting at the Domain level is probably the right thing to do in this case; I did not realize that you were trying to store an object in the Row.

FWIW, remember that Atlas is intended to model the persistence layer, not the domain layer. With that design constraint in mind, I wrote the Row::assertValidValue() method to make sure that only scalars and nulls could be set as values on a row, since scalars and nulls are the only things that move back and forth between PHP and the database. As such, the "right" place to create objects from Row values is in the domain layer.

However, I have lately begun to think that validation approach is a little too restrictive; in a future version of Atlas I expect to relax or remove it. Relaxing it in 2.x might be possible without breaking BC (and expectations) but I am not sure at this point.

Sorry for the hassle, and let me know if we can close this issue for now.

[pmjones]

Thanks for saying so @fadoe :-)