Liquibase اور Spring Boot کے ساتھ ڈیٹا بیس ورژن کنٹرول

درج ذیل مانوس منظر نامے پر غور کریں: میں ایک نئی خصوصیت پر کام کر رہا ہوں جس کے لیے ایک نئے ڈیٹا بیس کالم کی ضرورت ہے۔ اپنے مقامی ڈیٹا بیس کلائنٹ کو کھولیں اور ALTER TABLE بیانات لکھیں اور ان پر عمل کریں۔ کوڈ بالکل کام کرتا ہے۔ آپ اپنے جاوا کوڈ کا ارتکاب کرتے ہیں، اسے ذخیرے کی طرف دھکیلتے ہیں، اور پھر کچھ کافی لینے جاتے ہیں۔

چند گھنٹوں بعد، جب ٹیم کا ایک رکن برانچ کو کھینچتا ہے اور ایپلیکیشن چلاتا ہے، تو سب کچھ کریش ہو جاتا ہے۔

"ہیلو،” وہ پورے کمرے سے پوچھتے ہیں (یا سلیک چینل میں)، "کیا آپ نے اپنے ڈیٹا بیس میں تبدیلیاں کی ہیں؟”

آپ کو فوری طور پر احساس ہو گیا کہ آپ اپنی SQL اسکرپٹ کا اشتراک کرنا بھول گئے ہیں۔ بس اسے چیٹ میں چسپاں کریں۔ وہ اسے چلاتے ہیں۔ سب کچھ کام کرتا ہے۔ پھر، ایک ہفتہ بعد، اسٹیجنگ ماحول میں تعیناتی بالکل اسی وجہ سے ناکام ہوجاتی ہے۔ جب تک یہ کوڈ پروڈکشن تک پہنچ جائے گا، ہر کوئی پریشان کن سوال پوچھ رہا ہو گا، "مجھے کون سی ایس کیو ایل اسکرپٹ چلانی چاہیے؟”

اس صورتحال کو اسکیما ڈرفٹ کہا جاتا ہے۔ یہ تب ہوتا ہے جب ڈیٹا بیس کی حالت متعدد ماحول میں مختلف ہوتی ہے۔ اسٹیجنگ کا ایک اسکیما ہوتا ہے، پروڈکشن کا دوسرا ہوتا ہے، اور ہر ڈویلپر کی مقامی مشین اس کی اپنی اسنو فلیک ہوتی ہے جس کی جانچ نہیں کی گئی ڈیٹا بیس میں ترمیم ہوتی ہے۔

ڈیٹابیس کی تبدیلیوں کو دستی طور پر منظم کرنا تعیناتی کے مسائل اور ٹیم کے تعاون کے مسائل کو حل کرنے کا ایک طریقہ ہے۔ ایپلیکیشن کوڈ بے وطن اور تبدیل کرنا آسان ہے۔ ڈیٹا بیس اسٹور کی حالت۔ ڈیٹا بیس میں ناقابل یقین حد تک اچھی یادیں ہوتی ہیں اور بری منتقلی کو شاذ و نادر ہی بھول جاتے ہیں۔

Liquibase ڈیٹا بیس کی تبدیلیوں پر ورژن کنٹرول کے اصولوں کو لاگو کرکے اس مسئلے کو حل کرتا ہے۔ ایس کیو ایل فائل دینے اور لوگوں سے اسے چلانے کی توقع کرنے کے بجائے، آپ کوڈ میں اپنے ڈیٹا بیس کی تبدیلیوں کی وضاحت کرتے ہیں۔ یہ تبدیلیاں آپ کی درخواست کے ذخیرے کے ساتھ سفر کرتی ہیں اور خود بخود چلتی ہیں۔

ذیل میں ایک اعلیٰ سطحی جائزہ ہے کہ یہ فن تعمیر کیسے کام کرتا ہے۔

ایک ڈیٹا بیس کی تبدیلی کے سفر کے بارے میں سوچئے۔ ڈویلپر جاوا کوڈ کے ساتھ Git میں ڈیٹا بیس کی منتقلی کا ارتکاب کرتے ہیں۔ جب آپ کی CI/CD پائپ لائن (یا ٹیم ممبر) اس کوڈ کو کھینچتی ہے، تو آپ کا اسپرنگ بوٹ ایپلیکیشن شروع ہو جاتا ہے۔ تاہم، ایپ کے مکمل طور پر بوٹ ہونے اور ویب ٹریفک کو قبول کرنے سے پہلے، Liquibase اس عمل کو روکتا ہے۔ یہ ایک گیٹ کیپر کے طور پر کام کرتا ہے، ڈیٹا بیس سے منسلک ہوتا ہے اور کسی بھی مطلوبہ اسکیما تبدیلیوں کو لاگو کرتا ہے۔ یہ آپ کو یہ یقینی بنانے کی اجازت دیتا ہے کہ آپ کا ڈیٹا بیس بالکل اسی طرح سے میل کھاتا ہے جس کی آپ کوڈ کی توقع ہے اس سے پہلے کہ کوئی ایک صارف درخواست کرے۔

ڈیٹا بیس کی ورژننگ کیوں ضروری ہے۔

اگر آپ نے ٹیم پر مبنی ایپلی کیشنز پر کام کرنے میں کوئی وقت صرف کیا ہے، تو آپ نے فولڈر کے ڈھانچے کو اس طرح دیکھا ہوگا:

project-sql-scripts/
├── create_employee_table.sql
├── create_employee_table_final.sql
├── create_employee_table_final_v2.sql
├── add_email_column.sql
├── latest.sql
└── definitely_latest_use_this_one.sql

جملہ "اس ایس کیو ایل اسکرپٹ کو دستی طور پر چلائیں” نے بہت سے یادگار واقعات کو جنم دیا ہے۔

دستی ڈیٹا بیس اپ ڈیٹس کا استعمال پیمانے پر ناکامی کی ضمانت دیتا ہے۔ ایک نئے ڈویلپر کو آن بورڈ کرنا ایک آثار قدیمہ کی مہم بن جاتا ہے تاکہ یہ معلوم کیا جا سکے کہ مقامی اسکیما کیسے بنایا جائے۔ تعیناتیاں دباؤ والے واقعات بن جاتی ہیں جن کے لیے دستی سوالات کی ایک فہرست کی ضرورت ہوتی ہے جسے ایک خاص ترتیب میں انجام دیا جانا چاہیے۔

ورژن کنٹرول ڈیٹا بیس کی تبدیلیاں اسکیما کو کوڈ کے طور پر مانتی ہیں۔ جب ڈیٹا بیس کی تبدیلیاں آپ کی درخواست کی منطق کے ساتھ لاگو کی جاتی ہیں، تو آپ کچھ فوری فوائد حاصل کر سکتے ہیں:

• مستقل مزاجی: تمام ماحول (مقامی، سٹیجنگ، پیداوار) ایک ہی ترتیب میں ایک ہی تبدیلیوں کا اطلاق کرتے ہیں۔

• حفاظت: اسکرپٹ کو چھوڑ کر یا پرانے سوالات کو چلا کر انسانی غلطی کو ختم کریں۔

• گھڑی: Git کمٹ کو دیکھ کر، آپ بالکل دیکھ سکتے ہیں کہ آپ کا جاوا کوڈ اور ڈیٹا بیس اسکیما نئی خصوصیات کو سپورٹ کرنے کے لیے ایک ساتھ کیسے تبدیل ہوا۔

آپ کے کوڈ کے لیے گٹ حل شدہ ورژن کنٹرول۔ Liquibase آپ کے ڈیٹا بیس کو باغی بھائی بننے سے روکنے میں مدد کرتا ہے۔

Liquibase کیا ہے؟

بنیادی طور پر، Liquibase ایک ڈیٹا بیس کی منتقلی کا ٹول ہے جو اسکیما کی تبدیلیوں کو ٹریک کرتا ہے اور اسے قابل قیاس اور دہرانے کے قابل طریقے سے لاگو کرتا ہے۔

ڈھیلا ایس کیو ایل اسکرپٹ لکھنے کے بجائے، آپ "مائیگریشن” لکھتے ہیں (جسے چینج سیٹ بھی کہا جاتا ہے)۔ Liquibase ان فائلوں کو پڑھتا ہے، اصل ڈیٹا بیس کے اندر ٹریکنگ ٹیبلز سے ان کا موازنہ کرتا ہے، اور بالکل جانتا ہے کہ ڈیٹا بیس کو تازہ ترین رکھنے کے لیے کیا کرنے کی ضرورت ہے۔

Liquibase کو مؤثر طریقے سے استعمال کرنے کے لیے، آپ کو صرف چند تصوراتی اصطلاحات کو سمجھنے کی ضرورت ہے۔

• چینج لاگ: یہ ماسٹر فائل ہے۔ یہ بنیادی طور پر ایک فہرست ہے جو Liquibase کو بتاتی ہے کہ کون سی مائیگریشن فائلیں چلنی ہیں اور کس ترتیب میں۔

• سیٹ تبدیل کریں: ڈیٹا بیس میں ایک واحد جوہری تبدیلی۔ ٹیبل بنانا ایک ChangeSet ہے۔ گرمی کا اضافہ ایک اور چیز ہے۔

• ہجرت کی تاریخ: Liquibase میزیں ڈیٹا بیس میں خود بخود بن جاتی ہیں (کہا جاتا ہے)۔ DATABASECHANGELOG) یاد رکھتا ہے کہ کون سے ChangeSets پہلے ہی چلائے جا چکے ہیں۔

• چیکسم: ہر ChangeSet کے لیے تیار کردہ ایک منفرد ہیش۔ Liquibase اس کا استعمال اس بات کا پتہ لگانے کے لیے کرتا ہے کہ آیا کسی نے کسی فائل کو پہلے سے نافذ کرنے کے بعد خفیہ طور پر اس میں ترمیم کی ہے۔

Liquibase کو Spring Boot کے ساتھ ضم کرنے سے، ہجرت کا عمل مکمل طور پر ایپلی کیشن کے آغاز کے دوران خود بخود ہوتا ہے۔

سٹارٹ اپ کے دوران، ویب سرور کو HTTP ٹریفک حاصل کرنے کی اجازت دینے سے پہلے Liquibase کنٹرول کر لیتا ہے۔ ڈیٹا بیس سے جڑیں اور ٹریکنگ ٹیبل کو چیک کریں کہ کون سی ہجرت پہلے ہی چل چکی ہے۔ جب اسے مقامی فائل میں ایک نئی منتقلی ملتی ہے، تو یہ بیک وقت اپ ڈیٹس کو روکنے کے لیے ڈیٹا بیس کو لاک کر دیتا ہے، تبدیلیوں کو انجام دیتا ہے، ایک نئی تاریخ لکھتا ہے، اور آخر میں لاک کو جاری کرتا ہے۔ اس پورے عمل کے مکمل ہونے کے بعد ہی اسپرنگ بوٹ بوٹ ہوگا۔

Liquibase اسپرنگ بوٹ کے ویب سرور کو مکمل طور پر شروع کرنے سے پہلے چلتا ہے، لہذا آپ کی ایپلیکیشن پرانے ڈیٹا بیس اسکیما پر ٹریفک کی خدمت نہیں کرے گی۔ اگر منتقلی ناکام ہوجاتی ہے، تو آپ کی درخواست شروع نہیں ہوگی، آپ کے سسٹم کو سمجھوتہ شدہ حالت میں داخل ہونے سے بچائے گی۔

پروجیکٹ کی ترتیبات

اب جب کہ آپ تھیوری کو سمجھ گئے ہیں، آئیے کچھ پریکٹیکل بناتے ہیں۔ آئیے ایمپلائی مینجمنٹ API کے لیے ایک ڈیٹا بیس کی تہہ بنائیں۔

یہ پروجیکٹ استعمال کرتا ہے:

• Java 17+

• اسپرنگ بوٹ 3.x

• ماوین

• Liquibase

• H2 ڈیٹا بیس

ہم H2 استعمال کر رہے ہیں کیونکہ یہ ایک ان میموری ڈیٹا بیس ہے جسے انسٹال کرنے کی ضرورت نہیں ہے۔ آپ ڈوکر کنٹینر کو کنفیگر کیے یا ڈیٹا بیس سرور انسٹال کیے بغیر اس پروجیکٹ کو فوراً چلا سکتے ہیں۔ تاہم، جو کچھ آپ یہاں سیکھتے ہیں وہ بالکل اسی طرح PostgreSQL، MySQL، SQL Server، یا Oracle پر لاگو ہوتا ہے۔

جب آپ اس پراجیکٹ کو اسپرنگ انیشیلائزیشن کے ذریعے بناتے ہیں، تو آپ مندرجہ ذیل انحصار منتخب کرتے ہیں: Spring Web، Spring Data JPA، Liquibase Migration، اور H2 Database۔

آپ کا pom.xmlآپ انحصار چیک کر سکتے ہیں جو ایسا کرنے کے لیے اہم ہیں۔

    
        org.springframework.boot
        spring-boot-starter-web
    
    
        org.springframework.boot
        spring-boot-starter-data-jpa
    

    
        com.h2database
        h2
        runtime
    

    
        org.liquibase
        liquibase-core
    

اگلا، ہم H2 کے ساتھ بات چیت کرنے اور Liquibase فائلوں کو تلاش کرنے کے لیے Spring Boot کو ترتیب دیتے ہیں۔ آپ کا src/main/resources/application.properties ایک فائل بنائیں اور درج ذیل شامل کریں:

# H2 Database Configuration
spring.datasource.url=jdbc:h2:file:./data/employeedb;DB_CLOSE_DELAY=-1
spring.datasource.driverClassName=org.h2.Driver
spring.datasource.username=sa
spring.datasource.password=

# Enable H2 Console to inspect the database in your browser
spring.h2.console.enabled=true
spring.h2.console.path=/h2-console

# Liquibase Configuration
spring.liquibase.change-log=classpath:db/changelog/db.changelog-master.xml

آخری لائن سب سے اہم ہے۔ یہ اسپرنگ بوٹ کو بتاتا ہے کہ ڈیٹا بیس کی تبدیلیوں کی "ماسٹر لسٹ” کہاں تلاش کی جائے۔

نوٹ: ہم ان میموری ڈیٹا بیس کے بجائے فائل پر مبنی H2 ڈیٹا بیس استعمال کر رہے ہیں۔ ان میموری ڈیٹا بیس کے ساتھ مسئلہ یہ ہے کہ جب بھی آپ اسپرنگ بوٹ کو دوبارہ شروع کرتے ہیں، ڈیٹا بیس خود ہی مکمل طور پر مٹ جاتا ہے۔

جب بھی آپ بوٹ کرتے ہیں تو Liquibase اسکیما کو شروع سے دوبارہ بناتا ہے، لیکن فائل کی بنیاد پر اس ٹیوٹوریل (اور اصل مقامی ترقی) کے لیے، ایک ڈیٹا بیس بہت بہتر ہے۔ فائل پر مبنی ڈیٹا بیس کے ساتھ، آپ کا ڈیٹا، اور اس سے بھی اہم بات، آپ کی Liquibase کی تاریخ، درحقیقت ایپلیکیشن کے دوبارہ شروع ہونے پر برقرار رہتی ہے۔

Liquibase کے بنیادی تصورات کو سمجھیں۔

اپنا پہلا ٹیبل بنانے سے پہلے، آپ کو یہ سمجھنا ہوگا کہ Liquibase فائلوں کو کیسے منظم کرتا ہے۔ Liquibase ایک درجہ بندی کا ڈھانچہ استعمال کرتا ہے۔

اسے ایک کتاب کی طرح سوچیں۔ کہ changeLog یہ مندرجات کا جدول ہے، changeSets یہ ایک حقیقی باب ہے۔

1. ماسٹر تبدیلی لاگ: یہ داخلی نقطہ ہے۔ اس میں شاذ و نادر ہی اصل ڈیٹا بیس کی تبدیلیاں شامل ہوتی ہیں۔ اس کے بجائے، اس کا واحد کام دوسری فائلوں کو ایک مخصوص ترتیب میں شامل کرنا ہے۔

2. چائلڈ چینج لاگ: یہ گروپ سے متعلق تبدیلیاں ایک ساتھ گروپ کی جاتی ہیں۔

3. سیٹ تبدیل کریں: یہ اصل ایٹم ڈیٹا بیس کمانڈز ہیں (جیسے ٹیبل بنانا یا کالم شامل کرنا)۔

یہاں ایک بصری خرابی ہے کہ یہ درجہ بندی ایک حقیقی اسپرنگ بوٹ پروجیکٹ میں کیسے کام کرتی ہے۔

Liquibase ہجرت کو درجہ بندی کے مطابق منظم کرتا ہے۔ ایک واحد ماسٹر فائل کو برقرار رکھیں جو مندرجات کی میز کے طور پر کام کرتی ہے۔ اس ماسٹر فائل میں بہت کم اصل SQL کمانڈز ہیں۔ اس کے بجائے، واضح طور پر چائلڈ XML فائلوں کو سخت عمل درآمد کے حکم میں شامل کریں۔ ہر ذیلی فائل، جیسے 01-create-employees.xml) ایک یا زیادہ انفرادی ڈیٹا بیس کمانڈز پر مشتمل ہے جسے Liquibase changeSets کہتے ہیں۔

کوئی راستہ نہیں changeSet اس کی شناخت تین چیزوں سے منفرد ہے:

• ID: ایک منفرد تار (اکثر ایک نمبر یا جیرا ٹکٹ ID)۔

• مصنف: میں وہ شخص ہوں جس نے ہجرت لکھی۔

• فائل کا راستہ: یہ وہ جگہ ہے جہاں فائل واقع ہے۔

جب Liquibase چلتا ہے، تو آپ کو درج ذیل نظر آتا ہے: changeSetمواد کی ایک کرپٹوگرافک ہیش (چیکسم) کا حساب لگاتا ہے اور ڈیٹا بیس میں ID، مصنف اور چیکسم کو ریکارڈ کرتا ہے۔ اگلے سٹارٹ اپ پر، اگر ڈیٹا بیس میں ID، creator، اور فائل پاتھ کے درست امتزاج کو دوبارہ چیک کیا جاتا ہے، تو اسے چھوڑ دیا جائے گا۔

ایک ابتدائی ملازم سکیما بنائیں (ورژن 1)

آئیے پہلا ورژن لکھتے ہیں۔ آپ کو اپنے عملے کو ذخیرہ کرنے کے لیے ایک میز کی ضرورت ہوگی۔

سب سے پہلے، ایک ماسٹر فائل بنائیں. src/main/resources/db/changelog/db.changelog-master.xml:

اگلا، ہم اصل مائیگریشن فائل بناتے ہیں۔ src/main/resources/db/changelog/changes/01-create-employees.xml:

آئیے اس پر ایک نظر ڈالیں کہ ہم نے ابھی کیا کیا۔ ہم ہیں changeSet اور id "1” اور author "آشوتوشکریس”۔ اندرونی طور پر، ہم نے Liquibase کے XML نحو کا استعمال کرتے ہوئے جدولوں کی وضاحت کی۔

سادہ SQL کے بجائے XML کیوں استعمال کریں؟ کیونکہ Liquibase ڈیٹا بیس agnostic ہے۔ یہ عین مطابق XML PostgreSQL کے لیے درست خود بخود نحو تیار کرتا ہے۔SERIAL)، MySQL(AUTO_INCREMENT) یا اوریکل(IDENTITY)۔ آپ اپنی ساخت کی وضاحت کرتے ہیں، اور Liquibase اسے آپ کے مخصوص ڈیٹا بیس کی بولی میں ترجمہ کرتا ہے۔

اب اپنی اسپرنگ بوٹ ایپلیکیشن چلائیں۔ ٹرمینل آؤٹ پٹ پر ایک نظر ڈالیں۔ آپ کو درج ذیل سے ملتے جلتے نوشتہ جات نظر آئیں گے۔

Liquibase نے محسوس کیا کہ ڈیٹا بیس خالی ہے۔ ٹریکنگ ٹیبل کو خود بخود ٹریک کرتا ہے (DATABASECHANGELOG)، ہمارا مضمون پڑھیں changeSetمیں نے ٹیبل تخلیق کیا اور ایونٹ کو لاگ کیا۔

اپنی درخواست کو ابھی دوبارہ شروع کریں اور Liquibase دوبارہ چلے گا۔ لیکن آئیے اس بار اسے چیک کریں۔ DATABASECHANGELOG میز، اسے دیکھو id="1" اور author="ashutoshkrris" یہ پہلے ہی چل چکا ہے، اس لیے اسے خود بخود چھوڑ دیا جاتا ہے۔ آپ کا ڈیٹا بیس اب محفوظ طریقے سے ورژن میں ہے۔

بس کیا ہوا؟

اس مقام تک، Liquibase تھوڑا سا جادوئی محسوس کر سکتا ہے۔ XML فائل کو فولڈر میں رکھیں اور اسپرنگ بوٹ شروع کریں، جو آپ کے ڈیٹا بیس اسکیما کو تبدیل کر دے گا۔

تاہم، یہ سمجھنا ضروری ہے کہ Liquibase اندرونی طور پر کیسے کام کرتا ہے۔ آغاز کی ترتیب کو سمجھنے سے آپ کو یہ جاننے میں مدد ملے گی کہ آخرکار مسائل پیدا ہونے پر اپنی تعیناتی کو کیسے ڈیبگ کرنا ہے۔

جب اسپرنگ بوٹ ایپلیکیشن شروع ہوتی ہے، تو یہ فوری طور پر ویب درخواستوں کو قبول کرنا شروع نہیں کرتی ہے۔ پہلے ہم اندرونی اجزاء کو شروع کرتے ہیں: ایک بار جب Liquibase اجزاء بن جاتے ہیں، منتقلی کا عمل شروع ہوتا ہے۔

یہاں بالکل وہی ہے جو آغاز کے مرحلے میں ہوتا ہے:

آئیے عین ترتیب کا سراغ لگائیں۔ جب Spring Boot Liquibase کو شروع کرتا ہے، تو ٹول سب سے پہلے لاک ٹیبل سے استفسار کرتا ہے تاکہ اس بات کو یقینی بنایا جا سکے کہ موجودہ ڈیٹا بیس کو منتقل کرنے والی کوئی اور ایپلیکیشن مثال موجود نہیں ہے۔ اگر ساحل صاف ہو تو تالا لگا لیں۔ اس کے بعد یہ مقامی XML فائل کے لیے ایک کرپٹوگرافک چیکسم کا حساب لگاتا ہے، اس کا ڈیٹا بیس ریکارڈ سے موازنہ کرتا ہے، کسی بھی چھوٹی ہوئی تبدیلی کو انجام دیتا ہے، اور ان کو لاگ کرتا ہے۔ آخر میں، Tomcat ویب سرور کو غیر مقفل کریں تاکہ یہ محفوظ طریقے سے شروع ہو سکے۔

یہ آرڈر اس بات کو یقینی بناتا ہے کہ آپ کی درخواست صارف کی درخواست پر کارروائی نہ کرے اس سے پہلے کہ ڈیٹا بیس اسکیما صارف کی درخواست پر کارروائی کے لیے مکمل طور پر تیار ہو۔

آئیے اس پر ایک نظر ڈالتے ہیں کہ یہ ریکارڈز اور تالے دراصل ڈیٹا بیس کے اندر ہی کیسے نظر آتے ہیں۔ اب جب کہ ہم نے پہلے H2 کنسول کو کنفیگر کر لیا ہے، ہم خام میزوں کا معائنہ کر سکتے ہیں۔

جب آپ کی اسپرنگ بوٹ ایپلیکیشن چل رہی ہو، اپنا براؤزر کھولیں اور اس پر جائیں: http://localhost:8080/h2-console. JDBC URL کا استعمال کرتے ہوئے جڑیں۔ jdbc:h2:file:./data/employeedb صارف نام سے sa اور ایک خالی پاس ورڈ۔

آپ اس میں اپنے آپ کو دیکھ سکتے ہیں۔ employees میز آپ Liquibase کے ذریعہ خود بخود تیار کردہ دو اضافی میزیں بھی دیکھ سکتے ہیں۔ DATABASECHANGELOG اور DATABASECHANGELOGLOCK.

کہ DATABASECHANGELOG میز

یہ جدول آپ کی نقل مکانی کی حکمت عملی کا مرکز ہے۔ یہ اس ماحول میں کی گئی تمام ڈیٹا بیس تبدیلیوں کے مستقل لیجر کے طور پر کام کرتا ہے۔

اگر آپ بھاگتے ہیں۔ SELECT * FROM DATABASECHANGELOG;آپ اس طرح آؤٹ پٹ دیکھیں گے:

ID	مصنف	فائل کا نام	چلانے کی تاریخ	آپ کا حکم بجا لایا گیا ہے۔	EXECTYPE	MD5SUM	وضاحت	تبصرہ	ٹیگ	Liquibase	سیاق و سباق	لیبل	DEPLOYMENT_ID
1	اشوتوشکریس	db/changelog/changes/01-create-employees.xml	2026-05-30 13:11:35.937919	1	پھانسی دی گئی۔	9:66e7dcffb2b1902a4e9f01670cb5f192	createTable tableName=ملازم		null	4.31.1	null	null	0126894849

آئیے سب سے اہم کالموں کا تجزیہ کرتے ہیں۔

• ID، مصنف، فائل کا نام: یہ تینوں کالم ایک جامع کلید بناتے ہیں۔ وہ مل کر منفرد طور پر ایک ہی ہجرت کی شناخت کرتے ہیں۔

• عملدرآمد کی تاریخ اور حکم پر عمل درآمد کی تاریخ: یہ آپ کو بالکل بتاتا ہے کہ اسکرپٹ کو کب اور کس ترتیب سے عمل میں لایا گیا تھا۔

• MD5 کل: یہ XML فائل کا ایک کرپٹوگرافک ہیش ہے۔ جب Liquibase شروع ہوتا ہے، یہ مقامی XML فائل کو ہیش کرتا ہے اور اس کا اس کالم سے موازنہ کرتا ہے۔ اگر آپ فائل کو چلانے کے بعد خفیہ طور پر اس میں ترمیم کرتے ہیں، تو یہ ہیشز مماثل نہیں ہوں گی اور Liquibase ڈیٹا بیس کی حفاظت کے لیے اسٹارٹ اپ کو روک دے گا۔

• مثال کی اقسام: زیادہ تر معاملات میں یہ صرف کہتا ہے: EXECUTED. تاہم، یہ ایک اہم آڈٹ ٹریل فراہم کرتا ہے۔ اگر آپ جان بوجھ کر منتقلی کو چھوڑ دیتے ہیں اور Liquibase کمانڈ کا استعمال کرتے ہوئے اسے مکمل طور پر لاگ کرتے ہیں، MARK_RAN. اگر ہجرت کو چھوڑ دیا گیا تھا کیونکہ ایک شرط ناکام ہو گئی تھی، تو آپ درج ذیل دیکھیں گے: SKIPPED.

• ٹیگ: اسے اپنے ڈیٹا بیس اسکیما کے لیے گٹ ٹیگ کے طور پر سوچیں۔ Liquibase کو کسی بڑے ہائی رسک تعیناتی سے پہلے ڈیٹا بیس کی موجودہ حالت کو "ٹیگ” کرنے کے لیے کنفیگر کیا جا سکتا ہے، جیسے v1.4.0)۔ اگر آپ کی تعیناتی تنقیدی طور پر ناکام ہو جاتی ہے، تو آپ ایک رول بیک کمانڈ جاری کر سکتے ہیں جو Liquibase کو بعد میں لاگو ہونے والی تمام تبدیلیوں کو کالعدم کرنے کی ہدایت کرتی ہے۔ v1.4.0 ٹیگ

• سیاق و سباق: اس طرح آپ ماحول سے متعلق تبدیلیوں کا نظم کرتے ہیں۔ ChangeSet میں سیاق و سباق کی خصوصیات شامل کریں، جیسے )، وہ ہجرت صرف اس صورت میں چلے گی جب اسپرنگ بوٹ اسٹارٹ اپ کے وقت "dev” یا "qa” کو Liquibase میں منتقل کرے۔ پیداوار اس کو نظر انداز کرتی ہے۔

• لیبل: جبکہ سیاق و سباق ماحول کو نشانہ بناتا ہے، لیبل ٹاسک کے زمرے کو نشانہ بناتے ہیں۔ جیرا ٹکٹ نمبر (issue-842) یا ریلیز ٹرین (Q3-release)۔ یہ اعلی درجے کی ٹیموں کو باقی ڈیٹا بیس کو متاثر کیے بغیر فعالیت کے مخصوص ذیلی سیٹوں کو منتخب طور پر چلانے یا رول بیک کرنے کی اجازت دیتا ہے۔

کہ DATABASECHANGELOGLOCK میز

اگرچہ یہ میز چھوٹا ہے، لیکن یہ جدید تعیناتیوں میں بہت بڑا کردار ادا کرتا ہے۔

اگر آپ بھاگتے ہیں۔ SELECT * FROM DATABASECHANGELOGLOCK;ایک قطار ظاہر ہوتی ہے۔

ID	مقفل	لاک دیا گیا۔	مقفل
1	جھوٹ	null	null

تصور کریں کہ اسپرنگ بوٹ ایپلیکیشن کو کبرنیٹس کلسٹر میں تعینات کرنا ہے۔ Kubernetes کو ہدایت کرتا ہے کہ وہ بیک وقت تین ایک جیسے واقعات کو گھمائیں۔ تینوں مثالیں بالکل اسی ڈیٹا بیس سے جڑتی ہیں۔

اگر آپ تینوں مثالوں کو چلانے کی کوشش کرتے ہیں۔ CREATE TABLE بالکل اسی ملی سیکنڈ میں منتقلی ڈیٹا بیس میں ہم آہنگی کی خرابی کا سبب بنے گی۔ لاک ٹیبل اس کو روکتے ہیں۔ ڈیٹا بیس سیٹ تک پہنچنے کے لیے پہلی مثال LOCKED کو TRUE. دیگر دو مثالیں میز کو چیک کریں، لاک چیک کریں، اور شائستگی سے انتظار کریں۔

ٹربل شوٹنگ کی عملی تجاویز: بعض اوقات منتقلی کے دوران تعیناتیاں ناکام ہو سکتی ہیں (سرور طاقت کھو سکتا ہے)۔ اگر ایسا ہوتا ہے تو، Liquibase سیٹ اپ ہونے سے پہلے ہی مر سکتا ہے۔ LOCKED دوبارہ FALSE.

اگلی بار جب آپ ایپلیکیشن شروع کریں گے، لاگ غیر معینہ مدت تک منجمد ہوجائے گا اور پھر دہرائیں گے: Waiting for changelog lock....

اگر آپ کو یقین ہے کہ فی الحال کوئی اور ایپلیکیشن ہجرت نہیں کر رہی ہے، تو آپ اپنے ڈیٹا بیس کلائنٹ میں ایک سادہ SQL کمانڈ چلا کر اس مسئلے کو دستی طور پر حل کر سکتے ہیں۔

UPDATE DATABASECHANGELOGLOCK SET LOCKED = FALSE;

یہ لاک کو زبردستی کھولے گا اور ایپلیکیشن کو دوبارہ شروع کرنے کی اجازت دے گا۔

ایمپلائی API کا ارتقاء

سافٹ ویئر کبھی ختم نہیں ہوتا۔ کامیاب ورژن 1 کی تعیناتی کے دو ہفتے بعد، کاروباری ٹیم نئی ضروریات کے ساتھ واپس آتی ہے۔

اب جب کہ آپ سمجھ گئے ہیں کہ Liquibase ریکارڈز کو کیسے ٹریک کرتا ہے، اپنے ڈیٹا بیس کو تیار کرنا آسان ہے۔ بس ماسٹر لسٹ میں نئی ​​فائلیں شامل کریں۔

ورژن 2: ای میل فیلڈ شامل کریں۔

آپ کی HR ٹیم کو آپ کے ملازمین تک پہنچنے کی ضرورت ہے۔ مجھے ایک ای میل کالم کی ضرورت ہے۔

درج ذیل جگہ پر ایک نئی فائل بنائیں: src/main/resources/db/changelog/changes/02-add-employee-email.xml:

یہ آپ کا ہے۔ db.changelog-master.xml فائل کو پہلے شامل کے بالکل نیچے شامل کریں۔

جب آپ ایپلیکیشن کو دوبارہ شروع کرتے ہیں، تو Liquibase درج ذیل کو چیک کرتا ہے: DATABASECHANGELOG میز یہ دیکھتا ہے id="1" یہ پہلے سے موجود ہے، لہذا اسے چھوڑ دیں۔ یہ دیکھتا ہے id="2" چونکہ یہ غائب ہے، ہم اسے چلاتے ہیں اور ٹریکنگ ٹیبل میں ایک نئی قطار شامل کرتے ہیں۔

ورژن 3: ڈپارٹمنٹ سپورٹ شامل کیا گیا۔

کمپنی بڑھ رہی ہے۔ اب ملازمین کا تعلق محکموں سے ہے۔ تم ہو departments ایک میز اور ایک غیر ملکی کلیدی رکاوٹ جو دونوں کو جوڑتی ہے۔

بنانا 03-add-departments.xml:

نوٹ کریں کہ میں نے ایک فائل میں دو الگ الگ ChangeSets استعمال کیے ہیں۔ یہ بہترین عمل ہے۔ ہر ChangeSet ایک منطقی عمل کی نمائندگی کرتا ہے۔ اگر غیر ملکی کلید کی تخلیق (id=”4″) ناکام ہو جاتی ہے تو، ڈیپارٹمنٹ ٹیبل کی تخلیق (id=”3″) کو اب بھی کامیاب کے طور پر ریکارڈ کیا جائے گا اور صرف id=”4″ کو رول بیک کیا جائے گا۔

ورژن 4 اور 5: ملازم کی حیثیت اور کارکردگی کے اشارے

آخر میں، HR فعال اور غیر فعال ملازمین کو ٹریک کرنا چاہتا ہے، اور ڈیٹا بیس ٹیم کو معلوم ہو رہا ہے کہ آخری نام سے تلاش کرنا سست ہے۔

بنانا 04-status-and-indexes.xml:

تمام نئی فائلیں db.changelog-master.xml. شامل بیانات کی ترتیب وہی ترتیب ہے جس میں Liquibase ان پر عمل درآمد کرتا ہے۔

سنہری اصول: پھانسی شدہ تبدیلی سیٹ میں کبھی بھی ترمیم نہ کریں۔

بالآخر، آپ کی ٹیم کے ڈویلپرز کریں گے۔ 01-create-employees.xml اپنی فائل جمع کروائیں اور اپنی غلطیوں کا نوٹس لیں۔ شاید انہوں نے کالم کے نام میں ٹائپنگ کی غلطی پائی یا محسوس کیا کہ کالم میں کوئی سخت غیر null رکاوٹ نہیں ہے۔

معیاری جاوا کوڈ لکھنے کے سالوں پر مبنی ان کی جبلت، اس XML فائل کو کھولنا، غلطی کو درست کرنا، فائل کو محفوظ کرنا اور ایپلیکیشن کو دوبارہ شروع کرنا ہے۔

آئیے اصل میں اس کی کوشش کریں اور دیکھیں کہ کیا ہوتا ہے۔

آپ کا src/main/resources/db/changelog/changes/01-create-employees.xml فائل تبدیلی first_name گرمی given_name:

فائل کو محفوظ کریں اور اپنی اسپرنگ بوٹ ایپلیکیشن کو دوبارہ شروع کریں۔

ایک ہموار آغاز کے بجائے، ایپلیکیشن فوری طور پر کریش ہو جاتی ہے اور ٹرمینل میں ایک بہت بڑا اسٹیک ٹریس پیدا کرتی ہے۔ خرابی کے لاگ کے اوپری حصے کو قریب سے دیکھیں۔ آپ کو یہ درست پیغام نظر آئے گا:

Caused by: liquibase.exception.ValidationFailedException: Validation Failed:
     1 changesets check sum
          db/changelog/changes/01-create-employees.xml::1::ashutoshkrris was: 9:66e7dcffb2b1902a4e9f01670cb5f192 but is now: 9:2bd3ef21343d3b5c9448cc50bc35deef

ایسا کیوں ہوتا ہے اس کی وجہ یہ ہے: جب ایک ChangeSet کسی ماحول کے خلاف چلایا جاتا ہے، تو یہ ایک ناقابل تغیر ریکارڈ بن جاتا ہے۔ ماضی کو تبدیل نہیں کیا جا سکتا۔

جب Liquibase شروع ہوتا ہے، یہ مقامی XML فائل کے ایک کرپٹوگرافک ہیش (MD5 checksum) کا حساب لگاتا ہے۔ پھر DATABASECHANGELOG ایک ٹیبل بناتا ہے اور نئی کیلکولیشن کی گئی ہیش کا موازنہ اس ہیش سے کرتا ہے جب فائل پہلی بار چلائی گئی تھی۔

پہلے سے عملدرآمد شدہ فائل میں ایک کریکٹر کو تبدیل کرنے سے ہیش بدل جائے گی۔ Liquibase چھیڑ چھاڑ کا پتہ لگاتا ہے اور شروع کرنے سے انکار کرتا ہے۔ یہ آپ کے ڈیٹا کی حفاظت کے لیے ہے۔ اگر آپ کا XML کوڈ ظاہر کرتا ہے کہ کالم کے نام بتائے گئے ہیں: first_name تاہم، ڈیٹا بیس اصل میں استعمال کرتے ہوئے بنایا گیا تھا: fist_nameSpring Data JPA ذخیرہ بہرحال ناکام ہو جائے گا۔

مسئلہ حل کرنے کا طریقہ (صحیح طریقہ)

اگر آپ مقامی طور پر یہ غلطی کرتے ہیں، تو آپ ڈیٹا بیس میں جا کر قطار کو حذف کرنا چاہیں گے۔ DATABASECHANGELOG براہ کرم ایک ٹیبل منتخب کریں اور دوبارہ کوشش کریں۔ ایسا مت کرو۔ ایک بار جب یہ کوڈ سٹیجنگ یا پروڈکشن تک پہنچ جاتا ہے، تو آپ پروڈکشن سرور پر قطاروں کو دستی طور پر حذف نہیں کر پائیں گے۔

اسکیما کی غلطیوں کو ٹھیک کرنے کا صحیح طریقہ درج ذیل ہے: آگے بڑھو.

پہلے اپنی تبدیلیوں کو کالعدم کریں۔ 01-create-employees.xml ہیش ڈیٹا بیس کے خلاف مماثل ہے۔ اس کے بعد ہم ترمیم کو لاگو کرنے کے لیے ایک نیا ChangeSet بناتے ہیں۔

ماسٹر تبدیلی لاگ میں اس کو شامل کرنا اور ایپلیکیشن کو دوبارہ شروع کرنا ڈیٹا بیس کو محفوظ طریقے سے درست حالت میں لے جائے گا۔

بیج ڈیٹا آپریشنز

بعض اوقات اسکیما کو تبدیل کرنے کے لیے مفید ہونے کے لیے ابتدائی ڈیٹا کی ضرورت ہوتی ہے۔

مثال کے طور پر ورژن 3 میں departments میز میز اب بالکل خالی ہے۔ جب نئے ڈویلپرز ریپوزٹری کو کلون کرتے ہیں اور پروجیکٹ کو مقامی طور پر گھماتے ہیں، تو انہیں دستی طور پر SQL لکھنا پڑتا ہے۔ INSERT API کی جانچ کے لیے بیانات۔

آپ اپنی نقل مکانی کی حکمت عملی کے حصے کے طور پر بیس لائن ڈیٹا اندراجات بنا کر اسے خودکار کر سکتے ہیں۔

درج ذیل جگہ پر ایک نئی فائل بنائیں: src/main/resources/db/changelog/changes/05-seed-departments.xml:

بیان شامل کریں db.changelog-master.xml فائل جب آپ ایپلیکیشن کو دوبارہ شروع کریں گے، تو Liquibase ان قطاروں کو داخل کرے گا۔ آپ کا API اب استعمال کے لیے تیار ہے۔

ڈیٹا کی منتقلی کے خطرات

ڈیٹا سیڈنگ طاقتور ہے، لیکن نظم و ضبط کی ضرورت ہے۔ یہاں انگوٹھے کے کچھ عملی انجینئرنگ اصول ہیں:

Liquibase کے لیے استعمال کریں:

• جامد تلاش کی میزیں (اسٹیٹس کوڈ، ملک کی فہرست، ڈیفالٹ ڈیپارٹمنٹ)

• ایپلیکیشن کو بوٹ کرنے کے لیے سسٹم کنفیگریشن جھنڈوں کی ضرورت ہے۔

درج ذیل صورتوں میں Liquibase کا استعمال نہ کریں:

• ہم جانچ کے لیے ہزاروں جعلی صارفین بناتے ہیں۔

• لین دین کے اعداد و شمار کی بڑی مقدار کو منتقل کریں (مثلاً 5 ملین ریکارڈز کو ایک ٹیبل سے دوسرے میں منتقل کرنا)

ڈیٹا کی بڑی منتقلی ڈیٹا بیس ٹیبلز کو کئی گھنٹوں کے لیے مقفل کرنے کا سبب بن سکتی ہے۔ تعیناتی کے دوران کور ٹیبلز کو لاک کرنے سے آپ کی ایپلیکیشن کو بڑے پیمانے پر بندش کا سامنا کرنا پڑے گا۔ سکیما ڈھانچہ اور ضروری بیس لائن ڈیٹا پر چینج سیٹ پر توجہ دیں۔ بھاری ڈیٹا ہیرا پھیری کے لیے سرشار اسکرپٹس یا بیک گراؤنڈ ٹاسک استعمال کریں۔

رول بیک

ایک بہترین دنیا میں، آپ کا کوڈ ہمیشہ کام کرے گا۔ عملی طور پر، آپ ڈیٹا بیس کی تبدیلیوں کو تعینات کرتے ہیں جو پیداوار کے اہم سوالات یا کرپٹ ڈیٹا کو توڑ دیتے ہیں۔ جب ایسا ہوتا ہے تو مجھے انڈو بٹن کو دبانے کے لیے ایک طریقہ کی ضرورت ہوتی ہے۔

Liquibase رول بیکس کو سپورٹ کرتا ہے، لیکن آپ کو یہ سمجھنے کی ضرورت ہے کہ ان کی تشریح کیسے کی جائے۔

خودکار اور واضح رول بیک

بہت سے Liquibase کمانڈز خود بخود الٹ سکتے ہیں۔ مثال کے طور پر، اگر آپ اس طرح ایک ChangeSet لکھتے ہیں: یا Liquibase واضح طور پر جانتا ہے کہ کالم کو شامل کرنے کے برعکس کالم کو حذف کرنا ہے۔ آپ کو یہ بتانے کی ضرورت نہیں ہے کہ ان کارروائیوں کو کیسے کالعدم کیا جائے۔

تاہم، کچھ آپریشنز موروثی طور پر تباہ کن یا مبہم ہوتے ہیں۔ اپنی مرضی کے مطابق کب استعمال کریں۔ ٹیگز یا استعمال کریں۔ Liquibase ڈیٹا کو دوبارہ محفوظ کرنے کا طریقہ نہیں جانتا ہے۔ ان صورتوں میں، واضح رول بیک ہدایات فراہم کی جانی چاہئیں۔

آئیے ایک ایسے منظر نامے کی تقلید کرتے ہیں جہاں ہم ایک عارضی رسائی کوڈ کالم شامل کرتے ہیں۔ لیکن میں یہ جاننا چاہتا ہوں کہ اسے محفوظ طریقے سے کیسے ہٹایا جائے۔

بنانا 06-temporary-access.xml:

اسے اپنی ماسٹر فائل میں شامل کریں اور ایپلیکیشن چلائیں۔ ایک کالم شامل کیا گیا ہے۔

اگر آپ اسے اپنی CI/CD پائپ لائن کے ذریعے تعینات کرتے ہیں اور تعیناتی ناکام ہو جاتی ہے، تو آپ Liquibase Maven کمانڈ کو ایک مخصوص تعداد کے ذریعے واپس رول کرنے کے لیے متحرک کر سکتے ہیں، جیسے mvn liquibase:rollback -Dliquibase.rollbackCount=1) یا آپ ایک مخصوص ٹیگ پر واپس جا سکتے ہیں جیسا کہ پہلے بات کی گئی ہے۔

رول بیکس پر حقیقت کی جانچ

یہ جاننا ضروری ہے کہ رول بیکس کیسے کام کرتے ہیں، لیکن بیک اینڈ انجینئرنگ کی اصل دنیا یہ ہے: رول بیکس پر اکثر تبادلہ خیال کیا جاتا ہے، لیکن پیداواری ماحول میں شاذ و نادر ہی صاف ستھرا کام کیا جاتا ہے۔

کالم کو حذف کرنا ریاضی کے لحاظ سے آسان ہے۔ 15 منٹ کے دوران اس کالم میں ریکارڈ کردہ کسٹمر ڈیٹا کو بازیافت کرنا ناقابل یقین حد تک مشکل ہے کہ غلط کوڈ موجود تھا۔

اس کی وجہ سے، جدید انجینئرنگ ٹیمیں اکثر "رول فارورڈ” حکمت عملی کو ترجیح دیتی ہیں۔ اگر ہجرت سے کوئی مسئلہ پیدا ہوتا ہے، خوفناک ڈیٹا بیس رول بیک کمانڈ جاری کرنے کے بجائے، آپ فوری طور پر ایک نیا تبدیلی سیٹ بناتے ہیں جو مسئلہ کو حل کرتا ہے (جیسے گمشدہ انڈیکس کو شامل کرنا یا کسی رکاوٹ کو کم کرنا) اور ایپلیکیشن کو دوبارہ تعینات کریں۔

ڈیٹابیس کی تبدیلیوں کو اضافی اور غیر تباہ کن بنانے کے لیے ڈیزائن کرنا بہتر ہے تاکہ پہلے پیچیدہ رول بیکس کی ضرورت نہ ہو۔

عام ابتدائی غلطیاں

ڈیٹا بیس ورژن کنٹرول کو اپنانا کسی بھی انجینئرنگ ٹیم کے لیے ایک بڑا قدم ہے، لیکن یہ سیکھنے کے منحنی خطوط کے ساتھ آتا ہے۔ جب ڈویلپرز ڈھیلے SQL اسکرپٹ لکھنے سے Liquibase استعمال کرنے کی طرف منتقل ہوتے ہیں، تو وہ کچھ پیشین گوئی کرنے والے نقصانات میں پڑ جاتے ہیں۔

یہاں سب سے عام غلطیاں ہیں جو ابتدائی افراد کرتے ہیں اور ان سے کیسے بچنا ہے۔

1. "میگا” ترمیم سیٹ

شروع ہونے پر، یہ ایک XML فائل کے تحت پورے ابتدائی سکیما کو ایک واحد XML فائل میں پھینکنے کے لئے پرکشش ہے۔ changeSet. آپ وہاں 15 ڈال سکتے ہیں۔ createTable بیان اور 20 addForeignKeyConstraint بیان id="1".

یہ سادہ وجہ سے ایک خوفناک خیال ہے جس کی وجہ سے یہ معاہدہ ناکام ہو جاتا ہے۔

اگر ڈیٹابیس انجن ٹیبل نمبر 14 پر ناکام ہوجاتا ہے (نحوی غلطی کی وجہ سے)، پہلے 13 ٹیبلز کا کیا ہوتا ہے؟ کچھ ڈیٹا بیس انجن ٹرانزیکشنل ڈیٹا ڈیفینیشن لینگویج (DDL) کو سپورٹ کرتے ہیں۔ اس کا مطلب ہے کہ یہ خود بخود تمام 13 ٹیبلز کو واپس کر دیتا ہے۔ تاہم، بہت سے ڈیٹا بیس ایسا نہیں کرتے ہیں۔

اگر انٹرمیڈیٹ کی ناکامی ہوتی ہے تو، ڈیٹا بیس اب یتیم حالت میں ہوگا۔ Liquibase نے ریکارڈ نہیں کیا۔ id="1" اگر کامیاب ہوتا ہے، تو اگلی بار جب آپ ایپ شروع کریں گے تو یہ تمام 15 ٹیبلز کو دوبارہ بنانے کی کوشش کرے گا۔ چونکہ جدول 1 پہلے سے موجود ہے، اس لیے فوری تنازعہ ہے۔

اصلاحات: "ایک لاجیکل آپریشن فی چینج سیٹ” کے اصول پر عمل کریں۔ اگر آپ 3 ٹیبلز بنا رہے ہیں تو 3 علیحدہ ChangeSets بنائیں۔ اگر ایک بھی ناکام ہو جاتا ہے تو، کامیابی مستقل طور پر ریکارڈ کی جاتی ہے، اور صرف ٹوٹے ہوئے کو ٹھیک کرنے کی ضرورت ہے۔

2. دستی ڈیٹا بیس ٹیوننگ (غیر مرئی خطرہ)

یہ ترک کرنے کی سب سے خطرناک عادت ہے۔ ایک ڈویلپر نے پیداوار میں ایک گمشدہ اشاریہ دریافت کیا۔ Liquibase مائیگریشنز کو لکھنے، کوڈ کا جائزہ لینے اور تعینات کرنے کے بجائے، لاگ ان کریں اور انہیں براہ راست اپنے پروڈکشن ڈیٹا بیس پر چلائیں۔ CREATE INDEX وقت بچانے کے لیے دستی طور پر۔

ایک ہفتہ بعد، ایک اور ڈویلپر بالکل وہی انڈیکس بنانے اور تعینات کرنے کے لیے مناسب Liquibase منتقلی لکھتا ہے۔ سٹارٹ اپ پر ایپلیکیشن کریش ہو جاتی ہے۔ Liquibase چلانے کی کوشش کرے گا: CREATE INDEX میں نے کمانڈ چلائی، لیکن مجھے یہ کہتے ہوئے ایک غلطی ہوئی کہ ڈیٹا بیس میں انڈیکس پہلے سے موجود ہے۔

Liquibase کو اپناتے وقت، آپ کو درج ذیل بنیادی اصولوں کو قبول کرنا ہوگا: Liquibase اسکیموں کے بارے میں معلومات کا مکمل ذریعہ ہے۔ انسانی ہاتھ ڈیٹا بیس کی ساخت کے ساتھ براہ راست رابطے میں نہیں آنا چاہیے۔

اصلاحات: اگر کسی نے غلطی سے ایسا کیا ہے، تو آپ کے پاس اپنی تعیناتی پائپ لائن کو ٹھیک کرنے کے لیے دو اختیارات ہیں: آپ ڈیٹا بیس سے انڈیکس کو دستی طور پر حذف کر سکتے ہیں تاکہ Liquibase اسے مناسب طریقے سے دوبارہ بنا سکے، یا استعمال کریں: انڈیکس بنانے سے پہلے، Liquibase میں ٹیگ شامل کرکے یقینی بنائیں کہ انڈیکس موجود ہے۔

3. عمارت کو "شروع سے” نظر انداز کریں

اگر آپ کسی پروجیکٹ پر کئی مہینوں تک کام کرتے ہیں، تو آپ اپنے مقامی ڈیٹا بیس میں بہت سارے ریکارڈ جمع کر لیں گے۔ آپ یہ فرض کرتے ہوئے ایک ہجرت لکھتے ہیں کہ کچھ میزیں یا ٹیسٹ ڈیٹا پہلے سے موجود ہے۔

پھر ایک نیا ڈویلپر ٹیم میں شامل ہوتا ہے۔ جب میں کوڈ درآمد کرتا ہوں، خالی ڈیٹا بیس کو گھماتا ہوں، اور اسپرنگ بوٹ شروع کرتا ہوں، ہجرت درمیان میں پھنس جاتی ہے۔

ایسا اس لیے ہوتا ہے کیونکہ نقل مکانی ضمانت شدہ ریاستوں کے بجائے فرض شدہ ریاستوں پر انحصار کرتی ہے (جیسے کہ غیر ملکی کلید بنانے سے پہلے کچھ قطاروں کی موجودگی کی توقع کرنا)۔

اصلاحات: آپ کو اپنی ہجرت کو مکمل طور پر خالی ڈیٹا بیس کے خلاف باقاعدگی سے جانچنا چاہیے۔ اگر آپ Docker استعمال کرتے ہیں تو، ڈیٹا بیس کنٹینر کو پھاڑ دیں اور اسے دوبارہ بنائیں۔ اگر آپ فائل پر مبنی H2 ڈیٹا بیس استعمال کر رہے ہیں، جیسا کہ ہم نے پہلے ترتیب دیا ہے، تو اسے صرف حذف کر دیں۔ ./data/employeedb.mv.db پروجیکٹ فولڈر سے فائلوں کو حذف کریں اور اسپرنگ بوٹ کو دوبارہ شروع کریں۔ اگر آپ مکمل طور پر خالی ایپلیکیشن کے ساتھ کامیابی سے بوٹ نہیں کر سکتے ہیں، تو آپ کی منتقلی کی تاریخ خراب ہو گئی ہے۔

4. ہارڈ کوڈنگ ماحول کی تفصیلات

ابتدائی افراد براہ راست XML فائلوں میں ماحول سے متعلق مخصوص تفصیلات کو ہارڈ کوڈ کرنا چاہتے ہیں۔ مثال کے طور پر، آپ ایک مخصوص اسکیما نام (schemaName=”dev_schema”) کو ہارڈ کوڈ کر سکتے ہیں یا کسی مخصوص مقامی صارف کو اجازت دے سکتے ہیں (مائی_لوکل_صارف کو تمام ملازمین پر گرانٹ کریں)۔

جب یہ کوڈ اسٹیجنگ مرحلے میں منتقل ہوتا ہے، تو اسٹیجنگ ڈیٹا بیس مختلف اسکیما کا نام استعمال کرتا ہے اور تعیناتی ناکام ہوجاتی ہے۔

حل: نقل مکانی کو خلاصہ رکھیں۔ Spring Boot کو application.properties کے ذریعے کنکشن کی تفصیلات ہینڈل کرنے دیں۔ اگر آپ کو اپنی Liquibase فائل کے اندر متحرک اقدار کا استعمال کرنا ضروری ہے، تو جائیداد کا متبادل استعمال کریں۔ آپ Liquibase میں متغیرات کی وضاحت کر سکتے ہیں اور آغاز کے دوران انہیں Spring Boot میں منتقل کر سکتے ہیں۔

5. ہجرت کے آرڈر کو خراب کریں۔

Liquibase فائلوں کو اس ترتیب سے چلاتا ہے جس ترتیب سے وہ درج ہیں۔ db.changelog-master.xml فائل

ڈویلپر اے departments ٹیبل ایک برانچ میں ہے اور ڈویلپر B ایک غیر ملکی کلید بناتا ہے جو لنک کرتا ہے: departments دوسری شاخوں میں، جو بھی کوڈ کو ضم کرتا ہے وہ پہلے ترتیب کا تعین کرتا ہے۔ جب ڈویلپر بی کا کوڈ ماسٹر فائل میں شامل ہوتا ہے۔ پہلے ڈویلپر A کے کوڈ کا استعمال کرتے ہوئے، Liquibase ٹارگٹ ٹیبل کے موجود ہونے سے پہلے غیر ملکی کیز بنانے کی کوشش کرتا ہے۔

اصلاحات: ماسٹر تبدیلی لاگ ڈیٹا بیس کی تبدیلیوں کا حتمی گیٹ وے ہے۔ کوڈ کا جائزہ لینے کے دوران، ہمیشہ درج ذیل کو چیک کریں: بیانات کو تاریخ کے مطابق ترتیب دیا جاتا ہے اور انحصار بامعنی ہوتا ہے۔

Liquibase بمقابلہ Flyway بمقابلہ دستی ایس کیو ایل اسکرپٹ

جب آپ ڈیٹا بیس ورژن کنٹرول کو نافذ کرنے کا فیصلہ کرتے ہیں، تو آپ کو فوری طور پر ایک انتخاب کا سامنا کرنا پڑتا ہے۔ Liquibase جاوا ایکو سسٹم میں واحد ٹول نہیں ہے۔ سکیما ارتقاء کو منظم کرنے کے تین سب سے عام طریقے ہیں Liquibase، Flyway، اور دستی SQL اسکرپٹس۔

آپ کو ہر ایک کے عملی فوائد اور نقصانات کو سمجھنے کی ضرورت ہے تاکہ آپ اپنی مخصوص ٹیم اور پروجیکٹ کے لیے صحیح ٹول کا انتخاب کر سکیں۔

1. دستی ایس کیو ایل اسکرپٹ (بیس لائن)

یہ سب سے زیادہ beginners کے لئے پہلے سے طے شدہ نقطہ نظر ہے. ایک script.sql فائل بنائیں اور اسے براہ راست ڈیٹا بیس کے خلاف کسی ٹول جیسے DBeaver، pgAdmin، یا DataGrip کے ذریعے چلائیں۔

• طاقت: کوئی سیٹ اپ کی ضرورت نہیں ہے۔ آپ کا صحیح نحو پر مکمل کنٹرول ہے، اور تمام بیک اینڈ ڈویلپر پہلے ہی جانتے ہیں کہ SQL کیسے لکھنا ہے۔

• کمزوری: پھانسی کا کوئی سراغ نہیں ہے۔ یہ نقطہ نظر عملی طور پر ماحول میں اسکیما کے بڑھنے کی ضمانت دیتا ہے۔ تعیناتیاں دباؤ کا شکار ہوتی ہیں کیونکہ ان کا انحصار ان لوگوں پر ہوتا ہے جو صحیح ترتیب میں صحیح اسکرپٹ کو چلانا یاد رکھتے ہیں۔

• فیصلہ: مینوئل اسکرپٹس سولو ویک اینڈ پروجیکٹس یا تیز رفتار پروٹو ٹائپنگ کے لیے بالکل موزوں ہیں جہاں آپ کو اپنے ڈیٹا بیس کو تباہ کرنے میں کوئی اعتراض نہیں ہے۔ لیکن جس لمحے کوئی دوسرا ڈویلپر ٹیم میں شامل ہوتا ہے یا اسٹیجنگ ماحول پیدا ہوتا ہے، یہ ایک بہت بڑی ذمہ داری بن جاتی ہے۔

2. فلائی وے (ایس کیو ایل پیوریسٹ)

Flyway Liquibase کا سب سے مقبول متبادل ہے۔ Flyway XML یا YAML خلاصہ استعمال کرنے کے بجائے خام SQL قبول کرتا ہے۔ سخت نام دینے کے کنونشن (جیسے V1__Create_employee_table.sql) کا استعمال کرتے ہوئے ایک خالص SQL فائل بنائیں۔

• طاقت: سیکھنے کے لیے کوئی نئے جملے نہیں ہیں۔ اگر آپ ایس کیو ایل جانتے ہیں، تو آپ پہلے ہی جانتے ہیں کہ فلائی وے کو کیسے استعمال کرنا ہے۔ اسپرنگ بوٹ کے ساتھ بغیر کسی رکاوٹ کے سیٹ اپ، پر زور، اور انضمام کے لیے یہ ناقابل یقین حد تک تیز ہے۔

• کمزوری: چونکہ آپ خام SQL لکھ رہے ہیں، منتقلی آپ کے مخصوص ڈیٹا بیس بولی کے ساتھ مضبوطی سے جوڑ دی جاتی ہے۔ اگر آپ MySQL کے لیے Flyway سکرپٹ لکھتے ہیں اور بعد میں اپنے پروجیکٹ کو PostgreSQL میں منتقل کرنے کا فیصلہ کرتے ہیں، تو آپ کو اپنی منتقلی کی تاریخ کو دستی طور پر دوبارہ تخلیق کرنے کی ضرورت ہوگی۔ مزید برآں، سیملیس آٹومیٹک رول بیک فلائی وے کے تجارتی درجے کی ایک ادا شدہ خصوصیت ہے۔

• فیصلہ: فلائی وے ان ٹیموں کے لیے مثالی ہے جو SQL میں انتہائی ہنر مند ہیں، مستقل طور پر ایک ڈیٹابیس وینڈر کے لیے پابند ہیں، اور لچکدار ترتیب پر سخت قوانین کو ترجیح دیتی ہیں۔

3. Liquibase ( تجریدی تہہ)

جیسا کہ ہم نے اس پورے ٹیوٹوریل میں دیکھا ہے، Liquibase ڈیٹا بیس کی تبدیلیوں کو XML، YAML، یا JSON میں خلاصہ کرکے ایک مختلف طریقہ اختیار کرتا ہے۔

1. طاقت: یہ واقعی ڈیٹا بیس اجناسٹک ہے۔ ایک بار جب آپ اپنے منطقی ڈھانچے کی وضاحت کر لیتے ہیں، تو Liquibase خود بخود اسے H2، PostgreSQL، یا Oracle کے لیے درست SQL بولی میں تبدیل کر دیتا ہے۔ طاقتور خودکار رول بیکس، شرائط، سیاق و سباق، اور تعیناتی لیبلز کے لیے مفت سپورٹ۔

2. کمزوری: اس میں فلائی وے سے زیادہ تیز سیکھنے کا وکر ہے۔ XML نحو بلا شبہ لفظی ہے اور بہت آسان سنگل ٹیبل ایپلی کیشنز کے لیے بھاری لگ سکتا ہے۔

3. فیصلہ: Liquibase انٹرپرائز ماحول میں چمکتا ہے جس میں پیچیدہ ایپلی کیشنز، ملٹی ٹیننٹ سسٹمز، متعدد ڈیٹا بیس وینڈرز کو سپورٹ کرنے والے پروجیکٹس، اور CI/CD تعیناتی پائپ لائنوں پر دانے دار کنٹرول کی ضرورت ہوتی ہے۔

Liquibase بہترین طرز عمل

اب جب کہ آپ Liquibase کے میکانکس کو سمجھ چکے ہیں، آپ کو یہ جاننے کی ضرورت ہے کہ اسے پیشہ ورانہ ماحول میں کیسے استعمال کیا جائے۔ آپ کی مقامی مشین پر کام کرنے والی نقل مکانی کو لکھنا صرف آدھی جنگ ہے۔ ہجرتیں لکھنے کے لیے پوری ٹیم کے لیے نظم و ضبط کی ضرورت ہوتی ہے جسے پروڈکشن میں محفوظ طریقے سے تعینات کیا جا سکتا ہے۔

ڈیٹا بیس کی تبدیلیوں کا انتظام کرتے وقت اپنانے کے لیے انجینئرنگ کے بہترین طریقوں میں شامل ہیں:

1. ایک منطقی تبدیلی فی تبدیلی سیٹ (ایٹمی اصول)

ہم نے عام غلطیوں کے سیکشن میں اس پر تبادلہ خیال کیا ہے، لیکن اس کو دہرانے کے لیے کافی ضروری ہے۔ ٹیبل کی تخلیق، انڈیکس کی تخلیق، اور ڈیٹا کے اندراج کو ایک ہی تبدیلی کے سیٹ میں نہ باندھیں۔

اگر آپ تنخواہ کا کالم اور idx_employee_salary انڈیکس شامل کرتے ہیں تو انہیں ایک ہی فائل میں دو الگ الگ ChangeSets میں ڈالیں۔ اس طرح، یہاں تک کہ اگر انڈیکس کی تخلیق ناکام ہوجاتی ہے، کالم کی تخلیق محفوظ طریقے سے لاگ ان ہوجاتی ہے اور کوئی ڈیٹا بیس یتیم حالت نہیں ہوتی ہے۔

2. فائلوں کو بامعنی طور پر منظم اور نام دیں۔

فائل کا نام متعین نہ کریں۔ update1.xml یا new_changes.xml. فائل کا نام یہ بتاتا ہے کہ ڈیٹا بیس کیسے تیار ہوا۔

ایک سخت سابقہ ​​نظام کو اپنائیں. ہمارے منصوبے میں ہم 01-create-employees.xml اور 02-add-employee-email.xml. اصلی ٹیمیں جیرا ٹکٹ نمبر استعمال کر سکتی ہیں یا ورژن جاری کر سکتی ہیں، جیسے v1.2.0_ticket-482_add_email.xml)۔ آپ جو بھی اصول منتخب کرتے ہیں، کوڈ کے جائزوں کے دوران انہیں سختی سے نافذ کریں۔

3. ایپلیکیشن کوڈ کی طرح ڈیٹا بیس کی تبدیلیوں کو ہینڈل کریں۔

ڈیٹا بیس کی منتقلی جاوا کوڈ کے بالکل آگے سورس کنٹرول میں ہے۔ انہیں بالکل اسی سطح کی جانچ پڑتال کے ساتھ جانچا جانا چاہئے۔

Liquibase فائلوں پر مشتمل پل کی درخواست کا جائزہ لیتے وقت، انجینئرز کو پوچھنا چاہئے:

• کیا مجھے اس کالم پر انڈیکس کی ضرورت ہے؟

• کیا یہ ایک تباہ کن تبدیلی ہے (مثلاً کالم کا نام تبدیل کرنا) جو اس وقت چل رہی ایپلیکیشن کو توڑ دیتی ہے؟

• کیا مصنف نے حسب ضرورت SQL کے لیے واضح رول بیک ہدایات شامل کی ہیں؟

4. منتقلی کو CI/CD میں ضم کریں۔

ڈیٹا بیس کی منتقلی پروڈکشن سرورز کے خلاف دستی طور پر نہیں کی جانی چاہیے۔ آپ کی تعیناتی پائپ لائن کو اسے خود بخود ہینڈل کرنا چاہیے۔

ایک بار جب آپ اپنے کوڈ کو مین برانچ میں ضم کر لیتے ہیں، تو آپ کی CI/CD پائپ لائن (جیسے GitHub ایکشنز یا GitLab CI) کو آپ کی اسپرنگ بوٹ ایپلیکیشن کی تعمیر اور تعیناتی کرنی چاہیے۔ چونکہ ہم نے Liquibase کو اسپرنگ بوٹ کے آغاز کے سلسلے میں بنڈل کیا ہے، اس لیے ہماری ایپلیکیشن خود بخود ہمارے پروڈکشن ڈیٹا بیس کو ویب ٹریفک موصول ہونے سے پہلے منتقل کر دیتی ہے۔

ایک محفوظ، خودکار تعیناتی پائپ لائن میں شامل ہیں:

ایک پختہ تعیناتی پائپ لائن میں، انسانی ہاتھ پروڈکشن ڈیٹا بیس کو کبھی نہیں چھوتے۔ جب آپ پل کی درخواست کو ضم کرتے ہیں، تو CI/CD پائپ لائن آپ کا کوڈ بناتی ہے اور یونٹ ٹیسٹ چلاتی ہے۔ اپنی اسپرنگ بوٹ ایپلیکیشن کو اسٹیجنگ ماحول میں تعینات کریں جہاں Liquibase خود بخود لاک حاصل کر لیتا ہے اور سٹارٹ اپ کے دوران ہجرت چلاتا ہے۔ ایک بار توثیق ہوجانے کے بعد، اسی آرٹفیکٹ کو پروڈکشن میں فروغ دیا جاتا ہے اور وہی خودکار منتقلی کا عمل شروع ہوتا ہے۔

5. مستقبل میں ترمیم سے بچنے کے لیے اپنے ریکارڈز کو حذف کریں۔

اگر منتقلی والدین کے ماحول میں ناکام ہو جاتی ہے (جیسے سٹیجنگ یا پروڈکشن)، ڈیٹا بیس میں لاگ ان کریں اور DATABASECHANGELOG آپ دوبارہ کوشش کر سکتے ہیں۔

تبدیلی لاگ کی عدم تغیر کا احترام کیا جانا چاہیے۔ اگر آپ غلطی کرتے ہیں تو ٹوٹے ہوئے ٹیبل کو حذف کریں یا ایک نیا ChangeSet بنائیں جو ڈیٹا کی قسم کو ٹھیک کرتا ہے اور اسے جاوا بگ فکس کی طرح Git ورک فلو کے ذریعے آگے بڑھاتا ہے۔

حتمی خیالات

ڈیٹا بیس اسکیما کی تبدیلیوں کا انتظام کرنا پریشانی کا باعث نہیں ہے۔

اپنے ڈیٹا بیس اسکیما کو کوڈ کے طور پر استعمال کرنے سے دستی ایس کیو ایل اسکرپٹس کی بے ترتیبی ختم ہوجاتی ہے۔ یہ خوفناک "اسکیما ڈرفٹ” کو روکتا ہے، جہاں ہر ڈویلپر کا مقامی کمپیوٹر مختلف طریقے سے برتاؤ کرتا ہے۔ سب سے اہم بات یہ ہے کہ آپ اپنی تعیناتی کو قابل پیشن گوئی اور بورنگ بنائیں۔ یہ وہ تقسیم ہے جو آپ چاہتے ہیں۔

اس ٹیوٹوریل میں، ہم نے شروع سے ایک عملی اسپرنگ بوٹ ایپلی کیشن بنایا ہے۔ آپ نے سیکھا کہ Liquibase کس طرح ایپلیکیشن کے آغاز کو ہائی جیک کرتا ہے، ڈیٹا بیس کو لاک کرتا ہے، خفیہ چیکسم کا حساب لگاتا ہے، اور محفوظ طریقے سے بڑھتی ہوئی تبدیلیوں کو لاگو کرتا ہے۔ آپ نے ایک جدول کو ایک رشتہ دار اسکیما میں تیار کیا ہے، بیج کا ڈیٹا شامل کیا ہے، اور سیکھا ہے کہ کس طرح سب سے عام خرابیوں سے بچنا ہے جن میں ابتدائی افراد پڑتے ہیں۔

اگلی بار جب آپ اپنا اسپرنگ بوٹ پروجیکٹ شروع کریں تو دستی SQL کلائنٹ تک رسائی نہ کریں۔ Liquibase انحصار شامل کریں، ایک ماسٹر تبدیلی لاگ بنائیں، اور اپنے ڈیٹا بیس ورژن کو پہلے دن سے کنٹرول کرنا شروع کریں۔ آپ کا مستقبل خود (اور آپ کی ٹیم) آپ کا شکریہ ادا کرے گا۔