DbToolsStorage filename strategy

[SimonMellerin]

DbToolsStorage filename strategy

[jrmgx]

I'm interested in this feature, is it implemented? I'm a bit lost because it's marked as closed but no other information. Let me know :)

[pounard]

This was closed because we were targeting an MVP and didn't want to pollute our task list with potentially useless features. We wanted some user feedback in order to priorize tasks and features.

Originally, the idea of having a file strategy was to allow users to use their own directory structure for dumps, along some default implementations, such as <YEAR>/<MONTH>/ for example.

Further we'd like to have this hidden behind an FilenameStrategyInterface or such for allowing users to implement their own.

@jrmgx Is that what you'd need ?

[jrmgx]

I understand now, it's exactly what I need.
The use case is: I have a project with a global backup mechanism in place, but it needs the file to follow a specific naming convention.

[pounard]

Understood ! That's indeed a use case we would want to support as well.

OK, I leave this issue opened, we should be able to work on this within the next week, please do not hesitate asking for a status update.

[pounard]

@jrmgx feature is now implemented and will be part of the next release.

In order to use it, you need to ether extend MakinaCorpus\DbToolsBundle\Storage\AbstractFilenameStrategy if don't need to change the root storage directory, or implement MakinaCorpus\DbToolsBundle\Storage\FilenameStrategyInterface if you need it to be different (if you have a single database, you don't need to fully implement the interface, but you may simply change the default storage path in configuration instead).

One important thing, the final directory will always be the concatenation of the getRootDir() and the generateFilename() methods. Default getRootDir() implementations suffixes the root directory with the connection name as a folder, if you want to change this behavior you need to implement fully the interface.

Once done, you need to register your custom implementation using this:

# file: config/packages/db_tools.yaml
db_tools:
    storage:
        filename_strategy:
            my_dbal_connection_name: App\DbTools\Storage\MyCustomFilenameStrategy

The strategy can be a stateless class with no constructor arguments, case in which you don't need to register it into the container and let the extension will do it for you, or it be configured using the container, case in which you can replace the class name by the service identifier in configuration (since it's the best practice to leave the class name be the service identifier, it should not change the configuration in the end, but if you have multiple connections and need to register more than once the same class, you can name the services, it'll work).

Please note that while doing this, we introduced a minor API change in order to rationalize configuration, with a deprecated fallback: for registering the default root directory it's not db_tools.storage_directory anymore, but db_tools.storage.root_dir instead. If you don't change your configuration it will continue to work, but emit a deprecation notice while building the container.