Style de code pour les migrations Laravel

Bonjour à tous.





Pendant les cinq premières années de ma carrière de programmeur, j'ai travaillé sur un projet en interne, pendant les sept années suivantes j'ai travaillé dans diverses startups, avec une équipe de cinq développeurs maximum.





Maintenant, je travaille depuis quelques mois sur un projet avec plus de 20 développeurs, le travail est effectué simultanément dans environ 30 branches, il y a cinq environnements pour le développement de code (draft, dev, testing, hotfix, prod), chaque environnement a sa propre base de données (avant de déployer le kamit sur stand / environnement, un déploiement de test a lieu à l'aide d'une base de données séparée, c'est-à-dire que nous avons 10 bases de données distinctes pour cinq environnements).





Développer dans plusieurs branches n'est pas nouveau pour moi, je l'ai toujours fait. La découverte pour moi était que la version du code et la version du schéma de base de données ne sont en aucun cas synchronisées. Dans un petit projet, ce n'est pas un problème de supprimer le schéma entier et de le rouler dans son intégralité, cela prend quelques minutes; dans ce projet, rouler un schéma à partir de zéro avec ensemencement prend une heure.





Il y a un gros problème avec la façon de synchroniser la version du code et la version du schéma de base de données.





Ci-dessous, je vais vous parler des règles que j'ai acceptées pour moi-même et je serai heureux si vous partagez vos techniques et techniques qui vous aident à faire face à cette catastrophe.





Avertissement

Le code présenté ci-dessous est un code de combat obscurci, je ne l'ai pas débogué, il faudra peut-être le modifier avec un fichier. Je ne partage que des idées avec vous.





description du problème

, , , - -. .





, - , , , , , ? , ?





, , . , , , . , .





.





: " "

, . , migrations, , , .





, .





:





#   
php artisan migrate --path="services/best-team-servise/database/migrations/2021_02_04_240000_alter_data_model_table_add_unique_index.php" --pretend
#  --pretend    SQL      ,  

#    
php artisan migrate:rollback --step=1
#    ,   
      
      



,





php artisan ide-helper:models "Project\Models\DataModel"
      
      



:





php artisan db:seed --class=DataModelSeeder
      
      



? up() down() , , .





, , , .





Builder :





        $conn = (new DataModel())->connection;
        $builder = Schema::connection($conn);
      
      



( ):





        $isExists = $builder->hasColumn(
            'data_model',
            'deleted_at'
        );
      
      



, :





        if (!$isExists) {
            $builder->table(
                'data_model',
                function (Blueprint $table) {
                    $table->softDeletesTz();
                }
            );
        }
      
      



- , - , , , :





        $alias = (new DataModel())->connection;
        $builder = Schema
            ::connection($alias)
            ->getConnection()
            ->getDoctrineSchemaManager();

$existingIndexes = $builder->listTableIndexes('data_model');
      
      



Laravel , :





Blueprint::unique('index_name');
      
      



:





Blueprint::dropUnique('index_name');
      
      



Laravel , , , SQL, Laravel ? , !





SQL, :





DROP TRIGGER IF EXISTS trigger_name
    ON public.data_model;
CREATE TRIGGER trigger_name
    BEFORE INSERT
    ON public.data_model
    FOR EACH ROW
    EXECUTE PROCEDURE public.function_name();
      
      



, :





DROP TRIGGER IF EXISTS trigger_name
    ON public.data_model;
      
      



: " "

, 1000+ . 1000 , .





, 50+ , "" .









, create, alter, , drop.





.





alter_data_model_add_property_column
alter_data_model_alter_property_column_to_text
alter_data_model_alter_property_column_set_default_value
alter_data_model_create_index_on_code_type_columns
alter_data_model_create_unique_index_on_code_column
      
      



, , MVP.





:





#     
php artisan make:migration create_profile_table --create=profile

#     
php artisan make:migration add_confirmed_to_profile --table=profile
      
      



database/migrations , .





: , nullable()

, NOT NULL, , , , .





, .





nullable(), , .





, , - :





            $columns = Schema
            ::connection((new DataModel())->connection)
            ->getConnection()
            ->getDoctrineSchemaManager()
            ->listTableColumns($(new DataModel())->getTable());

            $data = [];
            foreach ($columns as $column) {
                $name = $column->getName();
/* @var array[] $record    */
                $exists = key_exists($name, $record);
                if ($exists) {
                    $data[$name] = $record[$name];
                }
            }

            $isSuccess = DataModel
                ::withTrashed()
                ->updateOrCreate(
                    ['uniqe_index_column' => $data['uniqe_index_column'],],
                    $data
                )->exists;
      
      



: , null

, , , , , .





Ou vous pouvez utiliser une valeur par défaut dans le code, mais je n'aime pas cette méthode, car il s'agit de code en dur, et cela tue la flexibilité de notre application. Le fonctionnement de l'application doit être configuré via des variables d'environnement, des fichiers de configuration ou des enregistrements de base de données.





Conclusion

Cet ensemble de règles n'est certainement pas absolu, tout d'abord nous tournons la tête et utilisons le bon sens.





Discutons dans les commentaires. Veuillez partager votre expérience.








All Articles