Everything you need to know about NexoPOS.
When the multistore module (NsMultiStore) is enabled, all module migration should necessarily use the "App\Classes\Schema". The reason for this is because that class, which already exists "Illuminate\Support\Facades\Schema", accepts filters. It's therefore required to use that so that on runtime, the multistore can inject a table prefix that matches a specific store the migration is running.
In fact, every module migration runs on each store. That's true because every store is isolated and has its own tables. This guide will then show you how to work with migrations when you plan to create a migration that should work on substores.
NexoPOS 4.x include a command that helps to generate a migration file for a Module.
php artisan modules:migration <ModuleNamespace>
Where "ModuleNamespace" is the actual module namespace you would like to create the migration on. You'll be asked to provide a Migration Name.
By convention, migration must have a single purpose. For example, if you would like to create a migration that updates the schema of your module, you'll then the migration name should start with "Update...", for example, "UpdateUsersTable", "UpdateOrdersAddCostColumn". If your migration plans to create a new table, you'll need to have "Create" at the beginning of the migration file, for example "CreateCommentsTable", "CreateUsersTable".
As we've mentioned before, if a table needs to be available on a substore, it needs to use the Schema provided by NexoPOS 4.x. Here is an example :
This is a more cleaner way than working with Hook and filter and setting that on all area where it's needed.
You might have some migration that doesn't need to be executed on multistore. It might be a migration for creating a single unit table that applies to the whole system. In that case, you then need to keep the original Schema class (included after having created the migration), and define a public property "multistore" which has "false" as a value.