create_all के बजाय माइग्रेशन क्यों आवश्यक हैं

वास्तविक apps विकसित होते रहते हैं, इसलिए आपकी tables को भी बदलना पड़ता है। Features बढ़ने पर आप columns जोड़ेंगे, fields के नाम बदलेंगे और पुराने fields हटाएँगे। 🔄

पहले देखी गई सीमा याद रखें: create_all केवल missing tables बनाता है। जो table पहले से मौजूद हो, उसे यह कभी नहीं बदलता।

एक लुभावना समाधान है table हटाकर फिर से बनाना। Demo में यह काम करता है, लेकिन इससे हर row deletes हो जाती है, जो production में अकल्पनीय है।

Live database पर raw ALTER TABLE को हाथ से चलाना अविश्वसनीय है। एक टाइपो या छूटा हुआ चरण data को corrupt कर सकता है और उसे आसानी से वापस ठीक नहीं किया जा सकता।

migration एक छोटी script होती है, जो आपके schema को एक version से अगले version तक सुरक्षित और दोहराए जा सकने वाले चरणों में ले जाती है।

हर migration की एक version id होती है और वह उससे पहले वाली migration की ओर संकेत करती है। साथ मिलकर वे हर schema change का क्रमबद्ध history बनाती हैं।

एक migration दो रास्ते परिभाषित करती है: upgrade बदलाव लागू करता है और कुछ गलत होने पर downgrade उसे वापस करता है।

Flask-Migrate आपके app को Alembic से जोड़ता है, जो schema changes पहचानकर आपके लिए migration scripts लिखने वाला tool है।

Migrations वर्तमान schema version को alembic_version नाम की table में दर्ज करती हैं, इसलिए tool को हमेशा पता रहता है कि आप कहाँ हैं।

वही migration scripts आपके laptop, CI और production में चलती हैं, इसलिए हर environment में identical schema तैयार होता है।

create_all का उपयोग केवल पहले prototype के लिए करें। जैसे ही आपका model बदलना शुरू हो, स्थायी रूप से migrations का उपयोग करें।

आपने देखा कि create_all schema को विकसित क्यों नहीं कर सकता और migrations सुरक्षित, versioned और वापस किए जा सकने वाले बदलाव कैसे लाती हैं। 🎉