സീറോ ഡൌൺടൈം വിന്യാസവും ഡാറ്റാബേസുകളും

വിന്യാസത്തിലെ ഡാറ്റാബേസ് അനുയോജ്യത പ്രശ്നങ്ങൾ എങ്ങനെ പരിഹരിക്കാമെന്ന് ഈ ലേഖനം വിശദമായി വിവരിക്കുന്നു. പ്രാഥമിക തയ്യാറെടുപ്പില്ലാതെ വിന്യസിക്കാൻ നിങ്ങൾ ശ്രമിക്കുകയാണെങ്കിൽ നിങ്ങളുടെ പ്രൊഡക്ഷൻ ആപ്ലിക്കേഷനുകൾക്ക് എന്ത് സംഭവിക്കുമെന്ന് ഞങ്ങൾ നിങ്ങളോട് പറയും. പൂജ്യം പ്രവർത്തനരഹിതമാകാൻ ആവശ്യമായ ആപ്ലിക്കേഷൻ ലൈഫ് സൈക്കിൾ ഘട്ടങ്ങളിലൂടെ ഞങ്ങൾ കടന്നുപോകും (ഏകദേശം. പാത: കൂടുതൽ - പൂജ്യം പ്രവർത്തനരഹിതമായ സമയം). ഞങ്ങളുടെ പ്രവർത്തനങ്ങളുടെ ഫലം, ബാക്ക്വേർഡ്-അനുയോജ്യമായ ഡാറ്റാബേസ് മാറ്റം ഒരു പിന്നിലേക്ക്-അനുയോജ്യമായ രീതിയിൽ പ്രയോഗിക്കുന്നതായിരിക്കും.

ലേഖനത്തിൽ നിന്നുള്ള കോഡ് ഉദാഹരണങ്ങൾ നിങ്ങൾക്ക് മനസിലാക്കണമെങ്കിൽ, നിങ്ങൾക്ക് അവ ഇവിടെ കണ്ടെത്താം സാമൂഹികം.

ആമുഖം

പൂജ്യം പ്രവർത്തനരഹിതമായ വിന്യാസം

എന്തൊരു നിഗൂഢത പൂജ്യം പ്രവർത്തനരഹിതമായ വിന്യാസം? ആപ്ലിക്കേഷൻ്റെ ഒരു പുതിയ പതിപ്പ് നിങ്ങൾക്ക് വിജയകരമായി അവതരിപ്പിക്കാൻ കഴിയുന്ന തരത്തിൽ നിങ്ങളുടെ ആപ്ലിക്കേഷൻ വിന്യസിക്കുമ്പോൾ നിങ്ങൾക്ക് ഇത് പറയാം, അതേസമയം ഉപയോക്താവ് അതിൻ്റെ ലഭ്യത ശ്രദ്ധിക്കുന്നില്ല. ഒരു ഉപയോക്താവിൻ്റെയും കമ്പനിയുടെയും വീക്ഷണകോണിൽ, ഇത് സാധ്യമായ ഏറ്റവും മികച്ച വിന്യാസ സാഹചര്യമാണ്, കാരണം ഇത് പുതിയ സവിശേഷതകൾ അവതരിപ്പിക്കാനും ബഗുകൾ തടസ്സമില്ലാതെ പരിഹരിക്കാനും അനുവദിക്കുന്നു.

ഇത് എങ്ങനെ നേടാം? നിരവധി മാർഗങ്ങളുണ്ട്, അവയിലൊന്ന് ഇതാ:

• നിങ്ങളുടെ സേവനത്തിൻ്റെ പതിപ്പ് നമ്പർ 1 വിന്യസിക്കുക
• ഒരു ഡാറ്റാബേസ് മൈഗ്രേഷൻ നടത്തുക
• പതിപ്പ് #2 ന് സമാന്തരമായി നിങ്ങളുടെ സേവനത്തിൻ്റെ #1 പതിപ്പ് വിന്യസിക്കുക
• പതിപ്പ് നമ്പർ 2 അത് പോലെ പ്രവർത്തിക്കുന്നതായി നിങ്ങൾ കാണുമ്പോൾ, പതിപ്പ് നമ്പർ 1 നീക്കം ചെയ്യുക
• ചെയ്‌തു!

എളുപ്പം, അല്ലേ? നിർഭാഗ്യവശാൽ, ഇത് അത്ര ലളിതമല്ല, ഞങ്ങൾ അത് പിന്നീട് വിശദമായി നോക്കാം. ഇപ്പോൾ നമുക്ക് മറ്റൊരു സാധാരണ വിന്യാസ പ്രക്രിയ പരിശോധിക്കാം - നീല പച്ച വിന്യാസം.

നിങ്ങൾ എപ്പോഴെങ്കിലും കേട്ടിട്ടുണ്ടോ നീല പച്ച വിന്യാസം? ക്ലൗഡ് ഫൗണ്ടറി ഇത് വളരെ എളുപ്പമാക്കുന്നു. വെറുതെ നോക്കൂ ഈ ലേഖനം, ഇവിടെ ഞങ്ങൾ ഇത് കൂടുതൽ വിശദമായി വിവരിക്കുന്നു. ചുരുക്കത്തിൽ, നീല പച്ച വിന്യാസം എങ്ങനെ ചെയ്യണമെന്ന് ഞങ്ങൾ നിങ്ങളെ ഓർമ്മിപ്പിക്കാം:

• നിങ്ങളുടെ പ്രൊഡക്ഷൻ കോഡിൻ്റെ രണ്ട് പകർപ്പുകൾ ("നീല", "പച്ച") പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക;
• എല്ലാ ട്രാഫിക്കും നീല പരിസ്ഥിതിയിലേക്ക് നയിക്കുക, അതായത്. അങ്ങനെ പ്രൊഡക്ഷൻ URL-കൾ അവിടെ പോയിൻ്റ് ചെയ്യുന്നു;
• എല്ലാ ആപ്ലിക്കേഷൻ മാറ്റങ്ങളും ഹരിത അന്തരീക്ഷത്തിൽ വിന്യസിക്കുകയും പരിശോധിക്കുകയും ചെയ്യുക;
• url നീലയിൽ നിന്ന് പച്ച പരിതസ്ഥിതിയിലേക്ക് മാറ്റുക

പ്രൊഡക്ഷൻ ബ്രേക്കിംഗിനെക്കുറിച്ച് ആകുലപ്പെടാതെ പുതിയ സവിശേഷതകൾ എളുപ്പത്തിൽ അവതരിപ്പിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു സമീപനമാണ് ബ്ലൂ ഗ്രീൻ വിന്യാസം. എന്തെങ്കിലും സംഭവിക്കുകയാണെങ്കിൽപ്പോലും, "ഒരു സ്വിച്ച് ഫ്ലിക്കുചെയ്യുന്നതിലൂടെ" നിങ്ങൾക്ക് മുമ്പത്തെ പരിതസ്ഥിതിയിലേക്ക് എളുപ്പത്തിൽ മടങ്ങാൻ കഴിയും എന്നതാണ് ഇതിന് കാരണം.

മേൽപ്പറഞ്ഞവയെല്ലാം വായിച്ചതിനുശേഷം, നിങ്ങൾക്ക് ചോദ്യം ചോദിക്കാം: പൂജ്യം പ്രവർത്തനരഹിതമായ സമയവും നീല പച്ച വിന്യാസവുമായി എന്ത് ബന്ധമുണ്ട്?

ശരി, അവയ്‌ക്ക് വളരെയധികം സാമ്യമുണ്ട്, കാരണം ഒരേ പരിതസ്ഥിതിയുടെ രണ്ട് പകർപ്പുകൾ പരിപാലിക്കുന്നതിന് അവ പരിപാലിക്കുന്നതിന് ഇരട്ടി പരിശ്രമം ആവശ്യമാണ്. ഇതാണ് ചില ടീമുകൾ അവകാശപ്പെടുന്നത് മാർട്ടിൻ ഫൗളർ, ഈ സമീപനത്തിൻ്റെ ഒരു വ്യതിയാനം പിന്തുടരുക:

വെബിനും ഡൊമെയ്ൻ ലെയറിനുമായി നീല-പച്ച സ്വിച്ചുകൾ സൃഷ്‌ടിച്ച് അതേ ഡാറ്റാബേസ് ഉപയോഗിക്കുന്നതാണ് മറ്റൊരു ഓപ്ഷൻ. ഈ സമീപനത്തിൽ, ഡാറ്റാബേസ് പലപ്പോഴും ഒരു പ്രശ്നമാകാം, പ്രത്യേകിച്ചും സോഫ്റ്റ്വെയറിൻ്റെ ഒരു പുതിയ പതിപ്പിനെ പിന്തുണയ്ക്കുന്നതിനായി നിങ്ങൾ അതിൻ്റെ സ്കീമ മാറ്റേണ്ടിവരുമ്പോൾ.

ഇവിടെ ഞങ്ങൾ ഈ ലേഖനത്തിലെ പ്രധാന പ്രശ്നത്തിലേക്ക് വരുന്നു. ഡാറ്റാബേസ്. ഈ വാചകം ഒന്നുകൂടി നോക്കാം.

ഒരു ഡാറ്റാബേസ് മൈഗ്രേഷൻ നടത്തുക.

ഇപ്പോൾ നിങ്ങൾ സ്വയം ഒരു ചോദ്യം ചോദിക്കണം - ഡാറ്റാബേസ് മാറ്റം പിന്നോട്ട് പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ എന്തുചെയ്യും? ആപ്പിൻ്റെ എൻ്റെ ആദ്യ പതിപ്പ് തകരില്ലേ? സത്യത്തിൽ ഇതുതന്നെയാണ് സംഭവിക്കുക...

അതിനാൽ, പൂജ്യം പ്രവർത്തനരഹിതമായ / നീല പച്ച വിന്യാസത്തിൻ്റെ വലിയ നേട്ടങ്ങൾ ഉണ്ടായിരുന്നിട്ടും, കമ്പനികൾ അവരുടെ ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കുന്നതിന് ഇനിപ്പറയുന്ന സുരക്ഷിതമായ പ്രക്രിയ പിന്തുടരുന്നു:

• ആപ്ലിക്കേഷൻ്റെ പുതിയ പതിപ്പ് ഉപയോഗിച്ച് ഒരു പാക്കേജ് തയ്യാറാക്കുക
• പ്രവർത്തിക്കുന്ന ഒരു ആപ്ലിക്കേഷൻ ഷട്ട് ഡൗൺ ചെയ്യുക
• ഡാറ്റാബേസ് മൈഗ്രേറ്റ് ചെയ്യുന്നതിന് സ്ക്രിപ്റ്റുകൾ പ്രവർത്തിപ്പിക്കുക
• ആപ്ലിക്കേഷൻ്റെ ഒരു പുതിയ പതിപ്പ് വിന്യസിക്കുകയും സമാരംഭിക്കുകയും ചെയ്യുക

ഈ ലേഖനത്തിൽ, സീറോ ഡൌൺടൈം വിന്യാസം പ്രയോജനപ്പെടുത്തുന്നതിന് നിങ്ങളുടെ ഡാറ്റാബേസും കോഡും ഉപയോഗിച്ച് നിങ്ങൾക്ക് എങ്ങനെ പ്രവർത്തിക്കാമെന്ന് ഞങ്ങൾ വിശദമായി പറയും.

ഡാറ്റാബേസ് പ്രശ്നങ്ങൾ

ഡാറ്റാബേസിൽ ഡാറ്റയൊന്നും സംഭരിക്കാത്ത ഒരു സ്‌റ്റേറ്റ്‌ലെസ് ആപ്പ് നിങ്ങളുടെ പക്കലുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് ഉടനടി സീറോ ഡൗൺടൈം വിന്യാസം ലഭിക്കും. നിർഭാഗ്യവശാൽ, മിക്ക സോഫ്‌റ്റ്‌വെയറുകൾക്കും എവിടെയെങ്കിലും ഡാറ്റ സംഭരിക്കേണ്ടതുണ്ട്. അതുകൊണ്ടാണ് സർക്യൂട്ടിൽ എന്തെങ്കിലും മാറ്റങ്ങൾ വരുത്തുന്നതിന് മുമ്പ് നിങ്ങൾ രണ്ടുതവണ ചിന്തിക്കേണ്ടത്. പ്രവർത്തനരഹിതമായ വിന്യാസം സാധ്യമാകുന്ന തരത്തിൽ സ്കീമ എങ്ങനെ മാറ്റാം എന്നതിൻ്റെ വിശദാംശങ്ങളിലേക്ക് കടക്കുന്നതിന് മുമ്പ്, നമുക്ക് ആദ്യം പതിപ്പിംഗ് സ്കീമയിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാം.

പതിപ്പ് സ്കീം

ഈ ലേഖനത്തിൽ ഞങ്ങൾ ഉപയോഗിക്കും ഫ്ലൈവേ ഒരു പതിപ്പ് നിയന്ത്രണ ഉപകരണമായി (ഏകദേശം. വിവർത്തനം: ഞങ്ങൾ ഡാറ്റാബേസ് മൈഗ്രേഷനെക്കുറിച്ചാണ് സംസാരിക്കുന്നത്). സ്വാഭാവികമായും, ഞങ്ങൾ ബിൽറ്റ്-ഇൻ ഫ്ലൈവേ പിന്തുണയുള്ള ഒരു സ്പ്രിംഗ് ബൂട്ട് ആപ്ലിക്കേഷനും എഴുതുകയും ആപ്ലിക്കേഷൻ സന്ദർഭം സജ്ജീകരിക്കുമ്പോൾ സ്കീമ മൈഗ്രേഷൻ നടത്തുകയും ചെയ്യും. ഫ്ലൈവേ ഉപയോഗിക്കുമ്പോൾ, മൈഗ്രേഷൻ സ്ക്രിപ്റ്റുകൾ നിങ്ങളുടെ പ്രോജക്റ്റ് ഫോൾഡറിൽ സംഭരിക്കാൻ കഴിയും (സ്ഥിരസ്ഥിതിയായി classpath:db/migration). അത്തരം മൈഗ്രേഷൻ ഫയലുകളുടെ ഒരു ഉദാഹരണം ഇവിടെ കാണാം

└── db
 └── migration
     ├── V1__init.sql
     ├── V2__Add_surname.sql
     ├── V3__Final_migration.sql
     └── V4__Remove_lastname.sql

ഈ ഉദാഹരണത്തിൽ നമ്മൾ 4 മൈഗ്രേഷൻ സ്ക്രിപ്റ്റുകൾ കാണുന്നു, അത് മുമ്പ് എക്സിക്യൂട്ട് ചെയ്തിട്ടില്ലെങ്കിൽ, ആപ്ലിക്കേഷൻ ആരംഭിക്കുമ്പോൾ ഒന്നിനുപുറകെ ഒന്നായി എക്സിക്യൂട്ട് ചെയ്യപ്പെടും. ഫയലുകളിലൊന്ന് നോക്കാം (V1__init.sql) ഒരു ഉദാഹരണം എന്ന നിലക്ക്.

CREATE TABLE PERSON (
id BIGINT GENERATED BY DEFAULT AS IDENTITY,
first_name varchar(255) not null,
last_name varchar(255) not null
);

insert into PERSON (first_name, last_name) values ('Dave', 'Syer');

എല്ലാം തികച്ചും സ്വയം വിശദീകരിക്കുന്നതാണ്: നിങ്ങളുടെ ഡാറ്റാബേസ് എങ്ങനെ പരിഷ്കരിക്കണമെന്ന് നിർവചിക്കുന്നതിന് നിങ്ങൾക്ക് SQL ഉപയോഗിക്കാം. സ്പ്രിംഗ് ബൂട്ടിനെയും ഫ്ലൈവേയെയും കുറിച്ചുള്ള കൂടുതൽ വിവരങ്ങൾക്ക്, പരിശോധിക്കുക സ്പ്രിംഗ് ബൂട്ട് ഡോക്‌സ്.

സ്പ്രിംഗ് ബൂട്ടിനൊപ്പം ഒരു സോഴ്സ് കൺട്രോൾ ടൂൾ ഉപയോഗിക്കുന്നതിലൂടെ, നിങ്ങൾക്ക് 2 വലിയ നേട്ടങ്ങൾ ലഭിക്കും:

• നിങ്ങൾ കോഡ് മാറ്റങ്ങളിൽ നിന്ന് ഡാറ്റാബേസ് മാറ്റങ്ങളെ വേർതിരിക്കുന്നു
• നിങ്ങളുടെ ആപ്ലിക്കേഷൻ്റെ റോൾഔട്ടിനൊപ്പം ഡാറ്റാബേസ് മൈഗ്രേഷൻ സംഭവിക്കുന്നു, അതായത്. നിങ്ങളുടെ വിന്യാസ പ്രക്രിയ ലളിതമാക്കിയിരിക്കുന്നു

ഡാറ്റാബേസ് പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നു

ലേഖനത്തിൻ്റെ അടുത്ത വിഭാഗത്തിൽ, ഡാറ്റാബേസ് മാറ്റങ്ങളിലേക്കുള്ള രണ്ട് സമീപനങ്ങളിൽ ഞങ്ങൾ ശ്രദ്ധ കേന്ദ്രീകരിക്കും.

• പിന്നോക്ക പൊരുത്തക്കേട്
• പിന്നോക്ക അനുയോജ്യത

ആദ്യത്തേത്, പ്രാഥമിക തയ്യാറെടുപ്പില്ലാതെ സീറോ ഡൌൺടൈം ഡിപ്ലോയ്‌മെൻ്റ് നടത്തരുതെന്ന മുന്നറിയിപ്പായി കണക്കാക്കും... രണ്ടാമത്തേത് പ്രവർത്തനരഹിതമായ ഒരു വിന്യാസം എങ്ങനെ നടത്താമെന്നും അതേ സമയം ബാക്ക്‌വേർഡ് കോംപാറ്റിബിലിറ്റി നിലനിർത്താമെന്നും ഉള്ള ഒരു പരിഹാരം വാഗ്ദാനം ചെയ്യുന്നു.

ഞങ്ങൾ പ്രവർത്തിക്കാൻ പോകുന്ന ഞങ്ങളുടെ പ്രോജക്റ്റ് ഒരു ലളിതമായ സ്പ്രിംഗ് ബൂട്ട് ഫ്ലൈവേ ആപ്ലിക്കേഷനായിരിക്കും Person с first_name и last_name ഡാറ്റാബേസിൽ (ഏകദേശം. വിവർത്തനം: Person ഒരു മേശയും first_name и last_name - ഇതിലെ വയലുകളാണ്). പേരുമാറ്റാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു last_name в surname.

അനുമാനങ്ങൾ

വിശദാംശങ്ങളിലേക്ക് കടക്കുന്നതിന് മുമ്പ്, ഞങ്ങളുടെ ആപ്ലിക്കേഷനുകളെക്കുറിച്ച് ഞങ്ങൾ കുറച്ച് അനുമാനങ്ങൾ നടത്തേണ്ടതുണ്ട്. ഞങ്ങൾ നേടാൻ ആഗ്രഹിക്കുന്ന പ്രധാന ഫലം വളരെ ലളിതമായ ഒരു പ്രക്രിയയായിരിക്കും.

Zametka. ബിസിനസ് പ്രോ-ടിപ്പ്. പ്രക്രിയകൾ ലളിതമാക്കുന്നതിലൂടെ നിങ്ങൾക്ക് പിന്തുണയിൽ ധാരാളം പണം ലാഭിക്കാൻ കഴിയും (നിങ്ങളുടെ കമ്പനിയിൽ കൂടുതൽ ആളുകൾ ജോലി ചെയ്യുന്നു, നിങ്ങൾക്ക് കൂടുതൽ പണം ലാഭിക്കാൻ കഴിയും)!

ഡാറ്റാബേസ് റോൾബാക്ക് ചെയ്യേണ്ടതില്ല

ഇത് വിന്യാസ പ്രക്രിയയെ ലളിതമാക്കുന്നു (ചില ഡാറ്റാബേസ് റോൾബാക്കുകൾ, ഇല്ലാതാക്കൽ റോൾബാക്ക് പോലെ, മിക്കവാറും അസാധ്യമാണ്). അപ്ലിക്കേഷനുകൾ മാത്രം പിൻവലിക്കാൻ ഞങ്ങൾ താൽപ്പര്യപ്പെടുന്നു. ഈ രീതിയിൽ, നിങ്ങൾക്ക് വ്യത്യസ്ത ഡാറ്റാബേസുകളുണ്ടെങ്കിൽപ്പോലും (ഉദാഹരണത്തിന്, SQL, NoSQL), നിങ്ങളുടെ വിന്യാസ പൈപ്പ്ലൈൻ സമാനമായിരിക്കും.

ആപ്ലിക്കേഷൻ ഒരു പതിപ്പ് തിരികെ കൊണ്ടുവരുന്നത് എല്ലായ്പ്പോഴും സാധ്യമായിരിക്കണം (ഇനിയില്ല)

റോൾബാക്ക് ആവശ്യമുള്ളപ്പോൾ മാത്രം ചെയ്യണം. നിലവിലെ പതിപ്പിൽ എളുപ്പത്തിൽ പരിഹരിക്കാനാകാത്ത ഒരു ബഗ് ഉണ്ടെങ്കിൽ, ഏറ്റവും പുതിയ വർക്കിംഗ് പതിപ്പിലേക്ക് മടങ്ങാൻ ഞങ്ങൾക്ക് കഴിയും. ഈ ഏറ്റവും പുതിയ പ്രവർത്തിക്കുന്ന പതിപ്പ് മുമ്പത്തേതാണെന്ന് ഞങ്ങൾ അനുമാനിക്കുന്നു. ഒന്നിലധികം റോൾഔട്ടുകൾക്കായി കോഡും ഡാറ്റാബേസ് അനുയോജ്യതയും നിലനിർത്തുന്നത് വളരെ ബുദ്ധിമുട്ടുള്ളതും ചെലവേറിയതുമാണ്.

കുറിപ്പ്. കൂടുതൽ വായനാക്ഷമതയ്ക്കായി, ഈ ലേഖനത്തിൽ ഞങ്ങൾ ആപ്ലിക്കേഷൻ്റെ പ്രധാന പതിപ്പ് മാറ്റും.

ഘട്ടം 1: പ്രാരംഭ അവസ്ഥ

അപ്ലിക്കേഷൻ പതിപ്പ്: 1.0.0
DB പതിപ്പ്: v1

അഭിപ്രായം

ഇത് ആപ്ലിക്കേഷൻ്റെ പ്രാരംഭ അവസ്ഥയായിരിക്കും.

ഡാറ്റാബേസ് മാറ്റങ്ങൾ

DB അടങ്ങിയിരിക്കുന്നു last_name.

CREATE TABLE PERSON (
id BIGINT GENERATED BY DEFAULT AS IDENTITY,
first_name varchar(255) not null,
last_name varchar(255) not null
);

insert into PERSON (first_name, last_name) values ('Dave', 'Syer');

കോഡ് മാറ്റങ്ങൾ

ആപ്ലിക്കേഷൻ വ്യക്തിഗത ഡാറ്റ സംഭരിക്കുന്നു last_name:

/*
 * Copyright 2012-2016 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package sample.flyway;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

@Entity
public class Person {
    @Id
    @GeneratedValue
    private Long id;
    private String firstName;
    private String lastName;

    public String getFirstName() {
        return this.firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    public String getLastName() {
        return this.lastName;
    }

    public void setLastName(String lastname) {
        this.lastName = lastname;
    }

    @Override
    public String toString() {
        return "Person [firstName=" + this.firstName + ", lastName=" + this.lastName
                + "]";
    }
}

പിന്നിലേക്ക് അനുയോജ്യമല്ലാത്ത കോളം പുനർനാമകരണം

ഒരു കോളത്തിൻ്റെ പേര് എങ്ങനെ മാറ്റാം എന്നതിൻ്റെ ഒരു ഉദാഹരണം നോക്കാം:

ശ്രദ്ധ. ഇനിപ്പറയുന്ന ഉദാഹരണം മനഃപൂർവം കാര്യങ്ങൾ തകർക്കും. ഡാറ്റാബേസ് അനുയോജ്യതയുടെ പ്രശ്നം തെളിയിക്കാൻ ഞങ്ങൾ ഇത് കാണിക്കുന്നു.

അപ്ലിക്കേഷൻ പതിപ്പ്: 2.0.0.BAD

DB പതിപ്പ്: v2bad

അഭിപ്രായം

നിലവിലെ മാറ്റങ്ങൾ ഒരേ സമയം രണ്ട് സന്ദർഭങ്ങൾ (പഴയതും പുതിയതും) പ്രവർത്തിപ്പിക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്നില്ല. അതിനാൽ, പൂജ്യം പ്രവർത്തനരഹിതമായ വിന്യാസം നേടാൻ പ്രയാസമായിരിക്കും (അനുമാനങ്ങൾ കണക്കിലെടുക്കുകയാണെങ്കിൽ, അത് യഥാർത്ഥത്തിൽ അസാധ്യമാണ്).

എ/ബി ടെസ്റ്റിംഗ്

ഞങ്ങൾക്ക് ഒരു ആപ്ലിക്കേഷൻ പതിപ്പ് ഉണ്ട് എന്നതാണ് നിലവിലെ സാഹചര്യം 1.0.0, പ്രൊഡക്ഷൻ, ഡാറ്റാബേസ് എന്നിവയിൽ വിന്യസിച്ചിട്ടുണ്ട് v1. ഞങ്ങൾ ആപ്ലിക്കേഷൻ്റെ രണ്ടാമത്തെ ഉദാഹരണമായ പതിപ്പ് വിന്യസിക്കേണ്ടതുണ്ട് 2.0.0.BAD, കൂടാതെ ഡാറ്റാബേസ് അപ്ഡേറ്റ് ചെയ്യുക v2bad.

ഘട്ടങ്ങൾ:

1. പതിപ്പ് ആപ്ലിക്കേഷൻ്റെ ഒരു പുതിയ ഉദാഹരണം വിന്യസിച്ചിരിക്കുന്നു 2.0.0.BADഏത് ഡാറ്റാബേസ് അപ്ഡേറ്റ് ചെയ്യുന്നു v2bad
2. ഡാറ്റാബേസിൽ v2bad കോളം last_name ഇപ്പോൾ നിലവിലില്ല - അത് മാറ്റി surname
3. ഡാറ്റാബേസും ആപ്ലിക്കേഷൻ അപ്‌ഡേറ്റും വിജയകരമായിരുന്നു, ചില സന്ദർഭങ്ങൾ പ്രവർത്തിക്കുന്നു 1.0.0, മറ്റുള്ളവർ - ഇൻ 2.0.0.BAD. എല്ലാം ഡാറ്റാബേസുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു v2bad
4. പതിപ്പിൻ്റെ എല്ലാ സന്ദർഭങ്ങളും 1.0.0 അവർ കോളത്തിലേക്ക് ഡാറ്റ തിരുകാൻ ശ്രമിക്കുമെന്നതിനാൽ പിശകുകൾ എറിയാൻ തുടങ്ങും last_nameആർ ഇപ്പോൾ നിലവിലില്ല
5. പതിപ്പിൻ്റെ എല്ലാ സന്ദർഭങ്ങളും 2.0.0.BAD പ്രശ്നങ്ങളില്ലാതെ പ്രവർത്തിക്കും

നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഞങ്ങൾ ഡാറ്റാബേസിലും ആപ്ലിക്കേഷനിലും പിന്നിലേക്ക് പൊരുത്തപ്പെടാത്ത മാറ്റങ്ങൾ വരുത്തുകയാണെങ്കിൽ, A/B പരിശോധന അസാധ്യമാണ്.

ആപ്ലിക്കേഷൻ റോൾബാക്ക്

A/B വിന്യാസം ചെയ്യാൻ ശ്രമിച്ചതിന് ശേഷം എന്ന് നമുക്ക് അനുമാനിക്കാം (ഏകദേശം. per.: രചയിതാവ് ഉദ്ദേശിച്ചത് ഇവിടെ A/B പരിശോധനയാണ്) പതിപ്പിലേക്ക് ആപ്ലിക്കേഷൻ തിരികെ കൊണ്ടുവരണമെന്ന് ഞങ്ങൾ തീരുമാനിച്ചു 1.0.0. ഡാറ്റാബേസ് റോൾബാക്ക് ചെയ്യാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നില്ലെന്ന് പറയാം.

ഘട്ടങ്ങൾ:

1. പതിപ്പ് ആപ്ലിക്കേഷൻ ഉദാഹരണം ഞങ്ങൾ നിർത്തുന്നു 2.0.0.BAD
2. ഡാറ്റാബേസ് ഇപ്പോഴും ഉണ്ട് v2bad
3. പതിപ്പ് മുതൽ 1.0.0 അത് എന്താണെന്ന് മനസ്സിലാകുന്നില്ല surname, ഞങ്ങൾ പിശകുകൾ കാണും
4. നരകം തകർന്നു, നമുക്ക് ഇനി തിരിച്ചുപോകാൻ കഴിയില്ല

നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഞങ്ങൾ ഡാറ്റാബേസിലും ആപ്ലിക്കേഷനിലും പിന്നിലേക്ക് പൊരുത്തപ്പെടാത്ത മാറ്റങ്ങൾ വരുത്തുകയാണെങ്കിൽ, ഞങ്ങൾക്ക് മുമ്പത്തെ പതിപ്പിലേക്ക് മടങ്ങാൻ കഴിയില്ല.

സ്ക്രിപ്റ്റ് എക്സിക്യൂഷൻ ലോഗുകൾ

Backward incompatible scenario:

01) Run 1.0.0
02) Wait for the app (1.0.0) to boot
03) Generate a person by calling POST localhost:9991/person to version 1.0.0
04) Run 2.0.0.BAD
05) Wait for the app (2.0.0.BAD) to boot
06) Generate a person by calling POST localhost:9991/person to version 1.0.0 <-- this should fail
07) Generate a person by calling POST localhost:9992/person to version 2.0.0.BAD <-- this should pass

Starting app in version 1.0.0
Generate a person in version 1.0.0
Sending a post to 127.0.0.1:9991/person. This is the response:

{"firstName":"b73f639f-e176-4463-bf26-1135aace2f57","lastName":"b73f639f-e176-4463-bf26-1135aace2f57"}

Starting app in version 2.0.0.BAD
Generate a person in version 1.0.0
Sending a post to 127.0.0.1:9991/person. This is the response:

curl: (22) The requested URL returned error: 500 Internal Server Error

Generate a person in version 2.0.0.BAD
Sending a post to 127.0.0.1:9995/person. This is the response:

{"firstName":"e156be2e-06b6-4730-9c43-6e14cfcda125","surname":"e156be2e-06b6-4730-9c43-6e14cfcda125"}

ഡാറ്റാബേസ് മാറ്റങ്ങൾ

പേരുമാറ്റുന്ന മൈഗ്രേഷൻ സ്ക്രിപ്റ്റ് last_name в surname

സ്രോതസ്സ് ഫ്ലൈവേ സ്ക്രിപ്റ്റ്:

CREATE TABLE PERSON (
id BIGINT GENERATED BY DEFAULT AS IDENTITY,
first_name varchar(255) not null,
last_name varchar(255) not null
);

insert into PERSON (first_name, last_name) values ('Dave', 'Syer');

പേരുമാറ്റുന്ന സ്ക്രിപ്റ്റ് last_name.

-- This change is backward incompatible - you can't do A/B testing
ALTER TABLE PERSON CHANGE last_name surname VARCHAR;

കോഡ് മാറ്റങ്ങൾ

ഞങ്ങൾ ഫീൽഡ് നാമം മാറ്റി lastName ഓൺ surname.

പിന്നിലേക്ക്-അനുയോജ്യമായ രീതിയിൽ കോളത്തിൻ്റെ പേര് മാറ്റുന്നു

നമ്മൾ അഭിമുഖീകരിച്ചേക്കാവുന്ന ഏറ്റവും സാധാരണമായ അവസ്ഥയാണിത്. നമുക്ക് പിന്നിലേക്ക് പൊരുത്തപ്പെടാത്ത മാറ്റങ്ങൾ വരുത്തേണ്ടതുണ്ട്. സീറോ-ഡൌൺടൈം വിന്യാസത്തിനായി, അധിക ഘട്ടങ്ങളില്ലാതെ ഡാറ്റാബേസ് മൈഗ്രേഷൻ പ്രയോഗിക്കരുതെന്ന് ഞങ്ങൾ ഇതിനകം തെളിയിച്ചിട്ടുണ്ട്. ലേഖനത്തിൻ്റെ ഈ വിഭാഗത്തിൽ, പിന്നോക്ക അനുയോജ്യത നിലനിർത്തിക്കൊണ്ട് ആവശ്യമുള്ള ഫലം നേടുന്നതിന് ഞങ്ങൾ ഡാറ്റാബേസ് മൈഗ്രേഷനുകൾക്കൊപ്പം ആപ്ലിക്കേഷൻ്റെ 3 വിന്യാസങ്ങൾ നടത്തും.

Zametka. ഞങ്ങൾക്ക് ഒരു പതിപ്പ് ഡാറ്റാബേസ് ഉണ്ടെന്ന് ഓർക്കുക v1. അതിൽ നിരകൾ അടങ്ങിയിരിക്കുന്നു first_name и last_name. നമ്മൾ മാറണം last_name ഓൺ surname. ഞങ്ങൾക്ക് ആപ്പ് പതിപ്പും ഉണ്ട് 1.0.0, ഇതുവരെ ഉപയോഗിക്കാത്തത് surname.

ഘട്ടം 2: കുടുംബപ്പേര് ചേർക്കുക

അപ്ലിക്കേഷൻ പതിപ്പ്: 2.0.0
DB പതിപ്പ്: v2

അഭിപ്രായം

ഒരു പുതിയ കോളം ചേർക്കുകയും അതിലെ ഉള്ളടക്കങ്ങൾ പകർത്തുകയും ചെയ്യുന്നതിലൂടെ, ഞങ്ങൾ പിന്നിലേക്ക് അനുയോജ്യമായ ഡാറ്റാബേസ് മാറ്റങ്ങൾ സൃഷ്ടിക്കുന്നു. അതേ സമയം, നമ്മൾ JAR റോൾബാക്ക് ചെയ്യുകയോ പഴയ JAR പ്രവർത്തിക്കുകയോ ചെയ്താൽ, അത് എക്സിക്യൂഷൻ സമയത്ത് തകരില്ല.

ഞങ്ങൾ ഒരു പുതിയ പതിപ്പ് പുറത്തിറക്കുകയാണ്

ഘട്ടങ്ങൾ:

1. ഒരു പുതിയ കോളം സൃഷ്ടിക്കാൻ ഒരു ഡാറ്റാബേസ് മൈഗ്രേഷൻ നടത്തുക surname. ഇപ്പോൾ നിങ്ങളുടെ DB പതിപ്പ് v2
2. നിന്ന് ഡാറ്റ പകർത്തുക last_name в surname. ശ്രദ്ധിക്കുകനിങ്ങൾക്ക് ഈ ഡാറ്റ ധാരാളം ഉണ്ടെങ്കിൽ, നിങ്ങൾ ബാച്ച് മൈഗ്രേഷൻ പരിഗണിക്കണം!
3. അവ ഉപയോഗിക്കുന്ന കോഡ് എഴുതുക രണ്ടും и новыйഒപ്പം പഴയത് കോളം. ഇപ്പോൾ നിങ്ങളുടെ ആപ്പ് പതിപ്പ് 2.0.0
4. കോളത്തിൽ നിന്നുള്ള മൂല്യം വായിക്കുക surname, ഇല്ലെങ്കിൽ null, അല്ലെങ്കിൽ എൽ നിന്ന്ast_nameഎങ്കിൽ surname വ്യക്തമാക്കിയിട്ടില്ല. നിങ്ങൾക്ക് ഇല്ലാതാക്കാം getLastName() കോഡിൽ നിന്ന്, അത് ഔട്ട്പുട്ട് ചെയ്യും null എന്നതിൽ നിന്ന് നിങ്ങളുടെ അപേക്ഷ പിൻവലിക്കുമ്പോൾ 3.0.0 ഇതിനായി 2.0.0.

നിങ്ങൾ സ്പ്രിംഗ് ബൂട്ട് ഫ്ലൈവേയാണ് ഉപയോഗിക്കുന്നതെങ്കിൽ, പതിപ്പ് ആരംഭിക്കുമ്പോൾ ഈ രണ്ട് ഘട്ടങ്ങൾ നടപ്പിലാക്കും 2.0.0 അപേക്ഷകൾ. നിങ്ങൾ ഡാറ്റാബേസ് പതിപ്പിംഗ് ഉപകരണം സ്വമേധയാ പ്രവർത്തിപ്പിക്കുകയാണെങ്കിൽ, ഇത് ചെയ്യുന്നതിന് നിങ്ങൾ രണ്ട് വ്യത്യസ്ത കാര്യങ്ങൾ ചെയ്യേണ്ടിവരും (ആദ്യം db പതിപ്പ് സ്വമേധയാ അപ്ഡേറ്റ് ചെയ്യുക, തുടർന്ന് പുതിയ ആപ്ലിക്കേഷൻ വിന്യസിക്കുക).

അത് പ്രധാനമാണ്. പുതുതായി സൃഷ്ടിച്ച കോളം ഓർക്കുക പാടില്ല എന്നു NULL അല്ല. നിങ്ങൾ ഒരു റോൾബാക്ക് ചെയ്യുകയാണെങ്കിൽ, പഴയ ആപ്ലിക്കേഷന് പുതിയ കോളത്തെക്കുറിച്ച് അറിയില്ല, അത് സമയത്ത് ഇൻസ്റ്റാൾ ചെയ്യുകയുമില്ല Insert. എന്നാൽ നിങ്ങൾ ഈ നിയന്ത്രണവും ചേർത്താൽ നിങ്ങളുടെ db ആയിരിക്കും v2, ഇതിന് പുതിയ നിരയുടെ മൂല്യം ക്രമീകരിക്കേണ്ടതുണ്ട്. ഇത് നിയന്ത്രണങ്ങളുടെ ലംഘനത്തിലേക്ക് നയിക്കും.

അത് പ്രധാനമാണ്. നിങ്ങൾ രീതി നീക്കം ചെയ്യണം getLastName(), കാരണം പതിപ്പിൽ 3.0.0 കോഡിൽ കോളം എന്ന ആശയമില്ല last_name. അതിനർത്ഥം അവിടെ null സജ്ജീകരിക്കും എന്നാണ്. നിങ്ങൾക്ക് രീതി ഉപേക്ഷിച്ച് ചെക്കുകൾ ചേർക്കാം null, എന്നാൽ കൂടുതൽ മെച്ചപ്പെട്ട പരിഹാരം യുക്തിയിൽ അത് ഉറപ്പാക്കുക എന്നതാണ് getSurname() നിങ്ങൾ ശരിയായ പൂജ്യമല്ലാത്ത മൂല്യം തിരഞ്ഞെടുത്തു.

എ/ബി ടെസ്റ്റിംഗ്

ഞങ്ങൾക്ക് ഒരു ആപ്ലിക്കേഷൻ പതിപ്പ് ഉണ്ട് എന്നതാണ് നിലവിലെ സാഹചര്യം 1.0.0, പ്രൊഡക്ഷൻ, ഡാറ്റാബേസ് എന്നിവയിൽ വിന്യസിച്ചു v1. പതിപ്പ് ആപ്ലിക്കേഷൻ്റെ രണ്ടാമത്തെ ഉദാഹരണം ഞങ്ങൾക്ക് വിന്യസിക്കേണ്ടതുണ്ട് 2.0.0ഏത് ഡാറ്റാബേസ് അപ്ഡേറ്റ് ചെയ്യും v2.

ഘട്ടങ്ങൾ:

1. പതിപ്പ് ആപ്ലിക്കേഷൻ്റെ ഒരു പുതിയ ഉദാഹരണം വിന്യസിച്ചിരിക്കുന്നു 2.0.0ഏത് ഡാറ്റാബേസ് അപ്ഡേറ്റ് ചെയ്യുന്നു v2
2. ഇതിനിടയിൽ ചില അഭ്യർത്ഥനകൾ പതിപ്പ് സന്ദർഭങ്ങൾ വഴി പ്രോസസ്സ് ചെയ്തു 1.0.0
3. അപ്‌ഡേറ്റ് വിജയകരമായിരുന്നു, കൂടാതെ നിങ്ങൾക്ക് പതിപ്പ് ആപ്ലിക്കേഷൻ്റെ ഒന്നിലധികം പ്രവർത്തിക്കുന്ന സന്ദർഭങ്ങളുണ്ട് 1.0.0 മറ്റ് പതിപ്പുകളും 2.0.0. എല്ലാവരും ഡാറ്റാബേസുമായി ആശയവിനിമയം നടത്തുന്നു v2
4. പതിപ്പ് 1.0.0 ഡാറ്റാബേസിലെ കുടുംബപ്പേര് കോളം ഉപയോഗിക്കുന്നില്ല, പക്ഷേ പതിപ്പ് 2.0.0 ഉപയോഗിക്കുന്നു. അവർ പരസ്പരം ഇടപെടുന്നില്ല, പിശകുകൾ ഉണ്ടാകരുത്.
5. പതിപ്പ് 2.0.0 പഴയതും പുതിയതുമായ കോളങ്ങളിൽ ഡാറ്റ സംഭരിക്കുന്നു, പിന്നാക്ക അനുയോജ്യത ഉറപ്പാക്കുന്നു

അത് പ്രധാനമാണ്. പഴയ/പുതിയ നിരയിൽ നിന്നുള്ള മൂല്യങ്ങളെ അടിസ്ഥാനമാക്കി ഇനങ്ങൾ കണക്കാക്കുന്ന എന്തെങ്കിലും അന്വേഷണങ്ങൾ നിങ്ങൾക്കുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് ഇപ്പോൾ തനിപ്പകർപ്പ് മൂല്യങ്ങൾ ഉണ്ടെന്ന് നിങ്ങൾ ഓർക്കണം (മിക്കവാറും അവ ഇപ്പോഴും മൈഗ്രേറ്റ് ചെയ്യുന്നതാണ്). ഉദാഹരണത്തിന്, അക്ഷരത്തിൽ ആരംഭിച്ച അവസാന നാമം (കോളം എന്തുതന്നെയായാലും) ഉപയോക്താക്കളുടെ എണ്ണം കണക്കാക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ A, ഡാറ്റ മൈഗ്രേഷൻ പൂർത്തിയാകുന്നതുവരെ (old → new കോളം) നിങ്ങൾ ഒരു പുതിയ കോളം അന്വേഷിക്കുകയാണെങ്കിൽ നിങ്ങൾക്ക് സ്ഥിരതയില്ലാത്ത ഡാറ്റ ഉണ്ടായിരിക്കാം.

ആപ്ലിക്കേഷൻ റോൾബാക്ക്

ഇപ്പോൾ ഞങ്ങൾക്ക് ആപ്പ് പതിപ്പുണ്ട് 2.0.0 കൂടാതെ ഡാറ്റാബേസ് ഇൻ v2.

ഘട്ടങ്ങൾ:

1. നിങ്ങളുടെ അപേക്ഷ പതിപ്പിലേക്ക് തിരികെ കൊണ്ടുവരിക 1.0.0.
2. പതിപ്പ് 1.0.0 ഡാറ്റാബേസിൽ ഒരു കോളം ഉപയോഗിക്കുന്നില്ല surname, അതിനാൽ റോൾബാക്ക് വിജയിക്കണം

DB മാറുന്നു

ഡാറ്റാബേസിൽ പേരുള്ള ഒരു കോളം അടങ്ങിയിരിക്കുന്നു last_name.

ഫ്ലൈവേ ഉറവിട സ്ക്രിപ്റ്റ്:

CREATE TABLE PERSON (
id BIGINT GENERATED BY DEFAULT AS IDENTITY,
first_name varchar(255) not null,
last_name varchar(255) not null
);

insert into PERSON (first_name, last_name) values ('Dave', 'Syer');

സ്ക്രിപ്റ്റ് ചേർക്കുക surname.

ശ്രദ്ധ. നിങ്ങൾ ചേർക്കുന്ന നിരയിലേക്ക് NOT NULL നിയന്ത്രണങ്ങളൊന്നും ചേർക്കാൻ കഴിയില്ലെന്ന് ഓർക്കുക. നിങ്ങൾ JAR റോൾബാക്ക് ചെയ്യുകയാണെങ്കിൽ, പഴയ പതിപ്പിന് ചേർത്ത കോളത്തെക്കുറിച്ച് യാതൊരു ധാരണയുമുണ്ടാകില്ല, അത് സ്വയമേവ NULL ആയി സജ്ജീകരിക്കും. അത്തരമൊരു പരിമിതി ഉണ്ടെങ്കിൽ, പഴയ ആപ്ലിക്കേഷൻ കേവലം തകരും.

-- NOTE: This field can't have the NOT NULL constraint cause if you rollback, the old version won't know about this field
-- and will always set it to NULL
ALTER TABLE PERSON ADD surname varchar(255);

-- WE'RE ASSUMING THAT IT'S A FAST MIGRATION - OTHERWISE WE WOULD HAVE TO MIGRATE IN BATCHES
UPDATE PERSON SET PERSON.surname = PERSON.last_name

കോഡ് മാറ്റങ്ങൾ

ഞങ്ങൾ ഡാറ്റ സംഭരിക്കുന്നു last_name, കൂടാതെ surname. അതേ സമയം ഞങ്ങൾ വായിക്കുന്നു last_name, ഈ കോളം ഏറ്റവും പ്രസക്തമായതിനാൽ. വിന്യാസ പ്രക്രിയയിൽ, ചില അഭ്യർത്ഥനകൾ ഇതുവരെ അപ്‌ഡേറ്റ് ചെയ്യാത്ത ഒരു ആപ്ലിക്കേഷൻ ഇൻസ്‌റ്റൻസ് വഴി പ്രോസസ്സ് ചെയ്‌തിരിക്കാം.

/*
 * Copyright 2012-2016 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package sample.flyway;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

@Entity
public class Person {
    @Id
    @GeneratedValue
    private Long id;
    private String firstName;
    private String lastName;
    private String surname;

    public String getFirstName() {
        return this.firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    /**
     * Reading from the new column if it's set. If not the from the old one.
     *
     * When migrating from version 1.0.0 -> 2.0.0 this can lead to a possibility that some data in
     * the surname column is not up to date (during the migration process lastName could have been updated).
     * In this case one can run yet another migration script after all applications have been deployed in the
     * new version to ensure that the surname field is updated.
     *
     * However it makes sense since when looking at the migration from 2.0.0 -> 3.0.0. In 3.0.0 we no longer
     * have a notion of lastName at all - so we don't update that column. If we rollback from 3.0.0 -> 2.0.0 if we
     * would be reading from lastName, then we would have very old data (since not a single datum was inserted
     * to lastName in version 3.0.0).
     */
    public String getSurname() {
        return this.surname != null ? this.surname : this.lastName;
    }

    /**
     * Storing both FIRST_NAME and SURNAME entries
     */
    public void setSurname(String surname) {
        this.lastName = surname;
        this.surname = surname;
    }

    @Override
    public String toString() {
        return "Person [firstName=" + this.firstName + ", lastName=" + this.lastName + ", surname=" + this.surname
                + "]";
    }
}

ഘട്ടം 3: കോഡിൽ നിന്ന് അവസാന_പേര് നീക്കംചെയ്യുന്നു

അപ്ലിക്കേഷൻ പതിപ്പ്: 3.0.0

DB പതിപ്പ്:v3

അഭിപ്രായം

കുറിപ്പ് per.: പ്രത്യക്ഷമായും, യഥാർത്ഥ ലേഖനത്തിൽ രചയിതാവ് ഈ ബ്ലോക്കിൻ്റെ വാചകം ഘട്ടം 2-ൽ നിന്ന് തെറ്റായി പകർത്തി. ഈ ഘട്ടത്തിൽ, കോളം ഉപയോഗിക്കുന്ന പ്രവർത്തനക്ഷമത നീക്കം ചെയ്യാൻ ലക്ഷ്യമിട്ടുള്ള ആപ്ലിക്കേഷൻ കോഡിൽ മാറ്റങ്ങൾ വരുത്തണം. last_name.

ഒരു പുതിയ കോളം ചേർക്കുകയും അതിലെ ഉള്ളടക്കങ്ങൾ പകർത്തുകയും ചെയ്യുന്നതിലൂടെ, ഞങ്ങൾ പിന്നിലേക്ക് അനുയോജ്യമായ ഡാറ്റാബേസ് മാറ്റങ്ങൾ സൃഷ്ടിച്ചു. കൂടാതെ, നമ്മൾ JAR റോൾബാക്ക് ചെയ്യുകയോ പഴയ JAR പ്രവർത്തിക്കുകയോ ചെയ്താൽ, അത് എക്സിക്യൂഷൻ സമയത്ത് തകരില്ല.

ആപ്ലിക്കേഷൻ റോൾബാക്ക്

നിലവിൽ ഞങ്ങൾക്ക് ആപ്പ് പതിപ്പുണ്ട് 3.0.0 ഡാറ്റാബേസും v3. പതിപ്പ് 3.0.0 എന്നതിലേക്ക് ഡാറ്റ സംരക്ഷിക്കുന്നില്ല last_name. ഇതിനർത്ഥം ഇൻ surname ഏറ്റവും കാലികമായ വിവരങ്ങൾ സംഭരിച്ചിരിക്കുന്നു.

ഘട്ടങ്ങൾ:

1. നിങ്ങളുടെ അപേക്ഷ പതിപ്പിലേക്ക് തിരികെ കൊണ്ടുവരിക 2.0.0.
2. പതിപ്പ് 2.0.0 ഉപയോഗങ്ങളും last_name и surname.
3. പതിപ്പ് 2.0.0 എടുക്കും surname, ഇത് പൂജ്യമല്ലെങ്കിൽ, അല്ലെങ്കിൽ -last_name

ഡാറ്റാബേസ് മാറ്റങ്ങൾ

ഡാറ്റാബേസിൽ ഘടനാപരമായ മാറ്റങ്ങളൊന്നുമില്ല. പഴയ ഡാറ്റയുടെ അന്തിമ മൈഗ്രേഷൻ നടത്താൻ ഇനിപ്പറയുന്ന സ്ക്രിപ്റ്റ് എക്സിക്യൂട്ട് ചെയ്യുന്നു:

-- WE'RE ASSUMING THAT IT'S A FAST MIGRATION - OTHERWISE WE WOULD HAVE TO MIGRATE IN BATCHES
-- ALSO WE'RE NOT CHECKING IF WE'RE NOT OVERRIDING EXISTING ENTRIES. WE WOULD HAVE TO COMPARE
-- ENTRY VERSIONS TO ENSURE THAT IF THERE IS ALREADY AN ENTRY WITH A HIGHER VERSION NUMBER
-- WE WILL NOT OVERRIDE IT.
UPDATE PERSON SET PERSON.surname = PERSON.last_name;

-- DROPPING THE NOT NULL CONSTRAINT; OTHERWISE YOU WILL TRY TO INSERT NULL VALUE OF THE LAST_NAME
-- WITH A NOT_NULL CONSTRAINT.
ALTER TABLE PERSON MODIFY COLUMN last_name varchar(255) NULL DEFAULT NULL;

കോഡ് മാറ്റങ്ങൾ

കുറിപ്പ് per.: ഈ ബ്ലോക്കിൻ്റെ വിവരണവും രചയിതാവ് ഘട്ടം 2-ൽ നിന്ന് തെറ്റായി പകർത്തി. ലേഖനത്തിൻ്റെ യുക്തിക്ക് അനുസൃതമായി, ഈ ഘട്ടത്തിലെ കോഡിലെ മാറ്റങ്ങൾ കോളവുമായി പ്രവർത്തിക്കുന്ന ഘടകങ്ങൾ അതിൽ നിന്ന് നീക്കം ചെയ്യുന്നതിനാണ് ലക്ഷ്യമിടുന്നത്. last_name.

ഞങ്ങൾ ഡാറ്റ സംഭരിക്കുന്നു last_name, കൂടാതെ surname. കൂടാതെ, ഞങ്ങൾ കോളത്തിൽ നിന്ന് വായിക്കുന്നു last_name, അത് ഏറ്റവും പ്രസക്തമായതിനാൽ. വിന്യാസ പ്രക്രിയയിൽ, ചില അഭ്യർത്ഥനകൾ ഇതുവരെ അപ്‌ഗ്രേഡ് ചെയ്യാത്ത ഒരു സന്ദർഭത്തിലൂടെ പ്രോസസ്സ് ചെയ്തേക്കാം.

/*
 * Copyright 2012-2016 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package sample.flyway;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

@Entity
public class Person {
    @Id
    @GeneratedValue
    private Long id;
    private String firstName;
    private String surname;

    public String getFirstName() {
        return this.firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    public String getSurname() {
        return this.surname;
    }

    public void setSurname(String lastname) {
        this.surname = lastname;
    }

    @Override
    public String toString() {
        return "Person [firstName=" + this.firstName + ", surname=" + this.surname
                + "]";
    }
}

ഘട്ടം 4: ഡാറ്റാബേസിൽ നിന്ന് ലാസ്റ്റ്_നെയിം നീക്കംചെയ്യുന്നു

അപ്ലിക്കേഷൻ പതിപ്പ്: 4.0.0

DB പതിപ്പ്: v4

അഭിപ്രായം

പതിപ്പ് കോഡ് വസ്തുത കാരണം 3.0.0 കോളം ഉപയോഗിച്ചില്ല last_name, നമ്മൾ തിരിച്ചു പോയാൽ എക്സിക്യൂഷൻ സമയത്ത് മോശമായ ഒന്നും സംഭവിക്കില്ല 3.0.0 ഡാറ്റാബേസിൽ നിന്ന് ഒരു കോളം നീക്കം ചെയ്തതിന് ശേഷം.

സ്ക്രിപ്റ്റ് എക്സിക്യൂഷൻ ലോഗുകൾ

We will do it in the following way:

01) Run 1.0.0
02) Wait for the app (1.0.0) to boot
03) Generate a person by calling POST localhost:9991/person to version 1.0.0
04) Run 2.0.0
05) Wait for the app (2.0.0) to boot
06) Generate a person by calling POST localhost:9991/person to version 1.0.0
07) Generate a person by calling POST localhost:9992/person to version 2.0.0
08) Kill app (1.0.0)
09) Run 3.0.0
10) Wait for the app (3.0.0) to boot
11) Generate a person by calling POST localhost:9992/person to version 2.0.0
12) Generate a person by calling POST localhost:9993/person to version 3.0.0
13) Kill app (3.0.0)
14) Run 4.0.0
15) Wait for the app (4.0.0) to boot
16) Generate a person by calling POST localhost:9993/person to version 3.0.0
17) Generate a person by calling POST localhost:9994/person to version 4.0.0

Starting app in version 1.0.0
Generate a person in version 1.0.0
Sending a post to 127.0.0.1:9991/person. This is the response:

{"firstName":"52b6e125-4a5c-429b-a47a-ef18bbc639d2","lastName":"52b6e125-4a5c-429b-a47a-ef18bbc639d2"}

Starting app in version 2.0.0

Generate a person in version 1.0.0
Sending a post to 127.0.0.1:9991/person. This is the response:

{"firstName":"e41ee756-4fa7-4737-b832-e28827a00deb","lastName":"e41ee756-4fa7-4737-b832-e28827a00deb"}

Generate a person in version 2.0.0
Sending a post to 127.0.0.1:9992/person. This is the response:

{"firstName":"0c1240f5-649a-4bc5-8aa9-cff855f3927f","lastName":"0c1240f5-649a-4bc5-8aa9-cff855f3927f","surname":"0c1240f5-649a-4bc5-8aa9-cff855f3927f"}

Killing app 1.0.0

Starting app in version 3.0.0

Generate a person in version 2.0.0
Sending a post to 127.0.0.1:9992/person. This is the response:
{"firstName":"74d84a9e-5f44-43b8-907c-148c6d26a71b","lastName":"74d84a9e-5f44-43b8-907c-148c6d26a71b","surname":"74d84a9e-5f44-43b8-907c-148c6d26a71b"}

Generate a person in version 3.0.0
Sending a post to 127.0.0.1:9993/person. This is the response:
{"firstName":"c6564dbe-9ab5-40ae-9077-8ae6668d5862","surname":"c6564dbe-9ab5-40ae-9077-8ae6668d5862"}

Killing app 2.0.0

Starting app in version 4.0.0

Generate a person in version 3.0.0
Sending a post to 127.0.0.1:9993/person. This is the response:

{"firstName":"cbe942fc-832e-45e9-a838-0fae25c10a51","surname":"cbe942fc-832e-45e9-a838-0fae25c10a51"}

Generate a person in version 4.0.0
Sending a post to 127.0.0.1:9994/person. This is the response:

{"firstName":"ff6857ce-9c41-413a-863e-358e2719bf88","surname":"ff6857ce-9c41-413a-863e-358e2719bf88"}

DB മാറുന്നു

താരതമ്യേന v3 ഞങ്ങൾ കോളം നീക്കം ചെയ്യുന്നു last_name കൂടാതെ വിട്ടുപോയ നിയന്ത്രണങ്ങൾ ചേർക്കുക.

-- REMOVE THE COLUMN
ALTER TABLE PERSON DROP last_name;

-- ADD CONSTRAINTS
UPDATE PERSON SET surname='' WHERE surname IS NULL;
ALTER TABLE PERSON ALTER COLUMN surname VARCHAR NOT NULL;

കോഡ് മാറ്റങ്ങൾ

കോഡിൽ മാറ്റങ്ങളൊന്നുമില്ല.

തീരുമാനം

നിരവധി ബാക്ക്‌വേർഡ്-അനുയോജ്യ വിന്യാസങ്ങൾ നടത്തി ഞങ്ങൾ ബാക്ക്‌വേർഡ്-അനുയോജ്യമായ കോളത്തിൻ്റെ പേര് മാറ്റം വിജയകരമായി പ്രയോഗിച്ചു. നടത്തിയ പ്രവർത്തനങ്ങളുടെ ഒരു സംഗ്രഹം ചുവടെ:

1. ആപ്ലിക്കേഷൻ പതിപ്പിൻ്റെ വിന്യാസം 1.0.0 с v1 ഡാറ്റാബേസ് സ്കീമ (നിരയുടെ പേര് = last_name)
2. ആപ്ലിക്കേഷൻ പതിപ്പിൻ്റെ വിന്യാസം 2.0.0, ഇതിൽ ഡാറ്റ സംഭരിക്കുന്നു last_name и surname. അപേക്ഷയിൽ നിന്ന് വായിക്കുന്നു last_name. ഡാറ്റാബേസ് പതിപ്പിലാണ് v2പോലുള്ള നിരകൾ അടങ്ങിയിരിക്കുന്നു last_name, ഒപ്പം surname. surname l ൻ്റെ ഒരു പകർപ്പാണ്ast_name. (ശ്രദ്ധിക്കുക: ഈ നിരയ്ക്ക് അസാധുവായ പരിമിതി ഉണ്ടാകരുത്)
3. ആപ്ലിക്കേഷൻ പതിപ്പിൻ്റെ വിന്യാസം 3.0.0, അതിൽ മാത്രം ഡാറ്റ സംഭരിക്കുന്നു surname കൂടാതെ കുടുംബപ്പേരിൽ നിന്ന് വായിക്കുന്നു. ഡാറ്റാബേസിനെ സംബന്ധിച്ചിടത്തോളം, അവസാന മൈഗ്രേഷൻ നടക്കുന്നു last_name в surname. ഒരു പരിമിതിയും NULL അല്ല നിന്ന് നീക്കം ചെയ്തു last_name. ഡാറ്റാബേസ് ഇപ്പോൾ പതിപ്പിലാണ് v3
4. ആപ്ലിക്കേഷൻ പതിപ്പിൻ്റെ വിന്യാസം 4.0.0 - കോഡിൽ മാറ്റങ്ങളൊന്നും വരുത്തിയിട്ടില്ല. ഡാറ്റാബേസ് വിന്യാസം v4, അത് നീക്കം ചെയ്യുന്നു last_name. ഇവിടെ നിങ്ങൾക്ക് ഡാറ്റാബേസിലേക്ക് നഷ്‌ടമായ ഏതെങ്കിലും നിയന്ത്രണങ്ങൾ ചേർക്കാൻ കഴിയും.

ഈ സമീപനം പിന്തുടരുന്നതിലൂടെ, ഡാറ്റാബേസ്/അപ്ലിക്കേഷൻ കോംപാറ്റിബിലിറ്റി തകർക്കാതെ നിങ്ങൾക്ക് എല്ലായ്പ്പോഴും ഒരു പതിപ്പ് തിരികെ കൊണ്ടുവരാൻ കഴിയും.

കോഡ്

ഈ ലേഖനത്തിൽ ഉപയോഗിച്ചിരിക്കുന്ന എല്ലാ കോഡുകളും ഇവിടെ ലഭ്യമാണ് സാമൂഹികം. അധിക വിവരണം ചുവടെയുണ്ട്.

പദ്ധതികൾ

റിപ്പോസിറ്ററി ക്ലോൺ ചെയ്ത ശേഷം, നിങ്ങൾ ഇനിപ്പറയുന്ന ഫോൾഡർ ഘടന കാണും.

├── boot-flyway-v1              - 1.0.0 version of the app with v1 of the schema
├── boot-flyway-v2              - 2.0.0 version of the app with v2 of the schema (backward-compatible - app can be rolled back)
├── boot-flyway-v2-bad          - 2.0.0.BAD version of the app with v2bad of the schema (backward-incompatible - app cannot be rolled back)
├── boot-flyway-v3              - 3.0.0 version of the app with v3 of the schema (app can be rolled back)
└── boot-flyway-v4              - 4.0.0 version of the app with v4 of the schema (app can be rolled back)

സ്ക്രിപ്റ്റുകൾ

ചുവടെയുള്ള സ്‌ക്രിപ്റ്റുകളിൽ വിവരിച്ചിരിക്കുന്ന സ്‌ക്രിപ്റ്റുകൾ നിങ്ങൾക്ക് പ്രവർത്തിപ്പിക്കാൻ കഴിയും, അത് ഡാറ്റാബേസിൽ പിന്നാക്ക-അനുയോജ്യവും അനുയോജ്യമല്ലാത്തതുമായ മാറ്റങ്ങൾ കാണിക്കും.

കാണാൻ പിന്നിലേക്ക് അനുയോജ്യമായ മാറ്റങ്ങളുള്ള കേസ്, റൺ:

./scripts/scenario_backward_compatible.sh

കാണാനും പിന്നിലേക്ക് പൊരുത്തപ്പെടാത്ത മാറ്റങ്ങളുള്ള കേസ്, റൺ:

./scripts/scenario_backward_incompatible.sh

സ്പ്രിംഗ് ബൂട്ട് സാമ്പിൾ ഫ്ലൈവേ

എല്ലാ ഉദാഹരണങ്ങളും എടുത്തതാണ് Spring Boot Sample Flyway.

നിങ്ങൾക്ക് ഒന്ന് നോക്കാവുന്നതാണ് http://localhost:8080/flyway, സ്ക്രിപ്റ്റുകളുടെ ഒരു ലിസ്റ്റ് ഉണ്ട്.

ഈ ഉദാഹരണത്തിൽ H2 കൺസോളും ഉൾപ്പെടുന്നു (at http://localhost:8080/h2-console) അതിനാൽ നിങ്ങൾക്ക് ഡാറ്റാബേസ് നില കാണാനാകും (ഡിഫോൾട്ട് jdbc URL ആണ് jdbc:h2:mem:testdb).

അധികമായി

• ഡാറ്റാബേസ് റീഫാക്ടറിംഗ് പാറ്റേണുകൾ
• തുടർച്ചയായ ഡെലിവറി

ഞങ്ങളുടെ ബ്ലോഗിലെ മറ്റ് ലേഖനങ്ങളും വായിക്കുക:

• കുബെർനെറ്റസ്: സിസ്റ്റം റിസോഴ്‌സ് മാനേജ്‌മെന്റ് കോൺഫിഗർ ചെയ്യേണ്ടത് എന്തുകൊണ്ട്?
• ടെക്ടൺ പൈപ്പ്ലൈൻ - കുബർനെറ്റസ്-നേറ്റീവ് പൈപ്പ്ലൈനുകൾ
• Nginx-നായി ഡൈനാമിക് മൊഡ്യൂളുകൾ നിർമ്മിക്കുന്നു
• ഹാഷികോർപ്പ് കോൺസലിന്റെ കുബർനെറ്റസ് ഓതറൈസേഷന്റെ ആമുഖം
• ClickHouse-ൽ നിന്ന് അനുമതിയില്ലാതെ ClickHouse-ലേക്ക് അനുമതിയോടെയുള്ള മൈഗ്രേഷൻ എന്തിലേക്ക് നയിച്ചു?
• Nginx വെബ് സെർവറിനൊപ്പം സ്പ്രിംഗ് ആപ്ലിക്കേഷനുകളുടെ ബ്ലൂ-ഗ്രീൻ വിന്യാസം

അവലംബം: www.habr.com