giannino1995 ha scritto:
e che V1_1__init.sql e V1_2__Add_Col_Dob.sql siano file prodotti dal software Flyway in modo automatico:
Noooo! Questi script li scrivono
a mano gli
sviluppatori!!!
Scenario (me lo invento dai, anche se banale ..): il big boss dice che l'applicazione di gestione degli ordini deve gestire un nuovo "stato" d'ordine, ovvero "Evaso parzialmente". Esisterà già di certo una tabella es. STATI_ORDINE e anche la tabella ORDINI (che ha una
foreign key verso STATI_ORDINE: ciascun ordine fa riferimento ad uno stato).
La tabella STATI_ORDINE potrebbe essere benissimo considerata una tabella di "descrizione". Sono quelle tabelle che tipicamente hanno solamente le colonne ID, DESCRIZIONE e generalmente anche un CODE univoco (perché sovente gli ID non sono trattati come "stabili" tra vari ambienti). Ma supponiamo per semplicità che gli ID siano stabili e predeterminabili.
La "versione" corrente gestita con Flyway ad esempio è V3_0. Questa aggiunta è relativamente "piccola", quindi facciamo una nuova versione 3.0.1. Quindi lo SVILUPPATORE scrive un nuovo file sql, es.:
V3_0_1__Aggiunta_Stato_Evaso_Parz.sql
che contiene:
INSERT INTO STATI_ORDINE (ID, DESCRIZIONE) VALUES (10, 'Evaso parzialmente');
(tutto qui ma è solo come esempio)
Nota: in Flyway i nomi degli script DEVONO seguire una certa forma, è descritta nella documentazione ufficiale:
https://flywaydb.org/documentation/migrations#naming
Quando qualcuno (ovviamente delegato a questo compito) farà eseguire la "migrazione" con Flyway su un certo ambiente, Flyway applicherà quello script, se non già eseguito in precedenza, lo farà quindi una volta sola e traccerà varie informazioni, risultato, data/ora, ecc...
giannino1995 ha scritto:
prima lo schema e poi i dati
Nooo! Quanti script, cosa contengono ecc... è tutto a discrezione degli sviluppatori. Chiaramente, se si parte già da "zero" con il DB usando Flyway, il primo/primi script saranno certamente quelli che andranno a fare delle CREATE TABLE, CREATE INDEX, ecc... Ovviamente ...
Ma è possibile che anche più avanti ci sia la necessità di creare ulteriori tabelle o altre strutture.
giannino1995 ha scritto:
spring.flyway.baseline-on-migrate=true sembrerebbe una specifica per produrre questi file .sql non per usarli.
Nooo! Flyway NON produce alcun script!
giannino1995 ha scritto:
vorrei solo capire spring.flyway.baseline-on-migrate a cosa serve nel mio script.
Il prefisso "spring." è solo per qualificare che è una property specifica di Spring Boot.
Premesso che Flyway personalmente non l'ho mai usato. Quindi ci sarebbe da leggersi la documentazione (ora non ne ho il tempo). Comunque la documentazione ufficiale di SB dice poco sul baseline-on-migrate:
spring.flyway.baseline-on-migrate
Default value: false
Whether to automatically call baseline when migrating a non-empty schema.
A livello di flyway (cioè su un SUO file di configurazione), la property corrispondente è: flyway.baselineOnMigrate
Ma l'opzione, come concetto è in generale "baselineOnMigrate". Nella documentazione del
migrate dice:
Whether to automatically call baseline when migrate is executed against a non-empty schema with no metadata table. This schema will then be baselined with the baselineVersion before executing the migrations. Only migrations above baselineVersion will then be applied.
This is useful for initial Flyway production deployments on projects with an existing DB.
Be careful when enabling this as it removes the safety net that ensures Flyway does not migrate the wrong database in case of a configuration mistake!
Prova a leggere ... se non fosse chiaro, vedo di leggere anche io meglio la documentazione.
P.S.: Uhhhh... che fatica ...... (a spiegarti le cose ....)