do you have any way (or it’s possible) to add some custom prefix in table names, for example, I am at work on a user module, I have an
account table. and I want to model or repository automatically add this prefix. for example
its good if it can be added on config files
p18g is random prefix for add to all of the tables for more security
In the TableGatewayFactory, you could get the prefix from the config, and then get on with creating the tablegateway:
//use statements here
class AccountTableGatewayFactory implements FactoryInterface
public function __invoke(ContainerInterface $container, $requestedName, array $options = null)
//get the database adaper
$dbAdapter = $container->get(AdapterInterface::class);
$resultSetPrototype = new ResultSet();
//get the table prefix from config
$tablePrefix = $container->get("config")["table_prefix"];
return new TableGateway($tablePrefix.'_account', $dbAdapter, null, $resultSetPrototype);
And then in a config file of your choice:
"table_prefix" => "pg18"
Thank you very much, But by this config, I have to set
table_prefix for each table manually, I looking for a method to add this setting just in one area, does laminas-db have this option?
I am afraid it does not by default - however you could introduce a subclass of AbstractTableGateway and handle the table prefix there. you will still need to change any references on the original TableGateway-class to your own implementation.
Sample code from the docs (I don’t know if you would need the GlobalAdapterFeature, but if I were to guess, you don’t.)
class MyTableGateway extends AbstractTableGateway
public function __construct($prefix)
$this->table = $prefix.'_my_table';
$prefix could come from a TableGatewayFactory where you get it from the configuration as mentioned in previous posts.
Why should the table gateway class be extended if only the name of the table is to be changed?
TableIdentifier can be used here and besides the table gateway this also works for the
Sql classes of laminas-db.
They asked for a option to set the prefix in one area - if setting a TableIdentifier would do that too, that’s cool and the idea with extending is to be entirely blamed on me thinking too big lol
I liked your idea with the factory more.
But regardless of that, I wouldn’t put so much energy into that component anymore because it will be marked as feature-complete.
Thank you, that means much to me coming from you
To be honest and after some thought, I like my first approach more too.
Ultimately, the choice is up to Voltan, though.
Regardless of the state of laminas-db, it is still widely used and installed in skeleton applications - which means that we do need to make do with laminas-db until someone comes up with a migration path to doctrine
You can always use something other than laminas-db because it is not a required dependency for laminas-mvc or Mezzio.
I have not used the component myself for several years.
Then your idea is to stop using
laminas-db and use another component for the database. What component is suggested?
Is laminas-db dead?
A widely used database component would be doctrine, I suppose the majority use this instead of laminas-db.
About the state of laminas-db, see this thread. It has been decided to mark laminas-db as “feature-complete”.
Then I should try updating my DB component doctrine, do you have any example or document for starting?
I am currently working on switching to Doctrine, too.
There’s a module for laminas which integrates the ORM: Introduction - Doctrine Doctrine ORM Module for Laminas whose docs are helping me greatly.
Doctrine also has an example which originally outlines the usage of hydrators together with laminas-form, there are some tricks to take away from that one:
A Complete Example using Laminas\Form - Doctrine Doctrine Laminas Hydrators
Thank you very much both of them are good documents, I will start to switch my projects to Doctrine in next days