database - لشركة - نقل بيانات من جدول الى اخر




تغيير جداول قاعدة البيانات في جانغو (6)

أنا أفكر في استخدام جانغو لمشروع أنا بدأت (في، لعبة المستندة إلى المستعرض) واحدة من الميزات أنا تروق أكثر يستخدم syncdb لإنشاء تلقائيا جداول قاعدة البيانات على أساس نماذج دجانغو تعريف ( وهي ميزة التي لا يمكن أن يبدو أن تجد في أي إطار آخر). كنت أفكر بالفعل هذا كان جيدا جدا ليكون صحيحا عندما رأيت هذا في الوثائق :

سيندسب لن يغير الجداول الموجودة

سينسدب إنشاء الجداول فقط للنماذج التي لم يتم تثبيتها بعد. لن يصدر أبدا عبارات ألتر تابل لمطابقة التغييرات التي تم إجراؤها على فئة نموذج بعد التثبيت. وغالبا ما تنطوي التغييرات على فئات النماذج ومخططات قواعد البيانات على شكل من أشكال الغموض، وفي هذه الحالات، يتعين على جانغو أن يخمن التغييرات الصحيحة التي يتعين إجراؤها. هناك خطر من فقدان البيانات الهامة في هذه العملية.

إذا قمت بإجراء تغييرات على نموذج وترغب في تغيير جداول قاعدة البيانات لمطابقة، استخدم الأمر سكل لعرض بنية سكل جديدة ومقارنتها مع مخطط الجدول الحالي الخاص بك للعمل على التغييرات.

ويبدو أن تغيير الجداول الموجودة يجب أن يتم "باليد".

ما أود أن أعرف هو أفضل وسيلة للقيام بذلك. هناك حلان يتبادران إلى الذهن:

  • كما توحي الوثائق، إجراء التغييرات يدويا في دب؛
  • قم بعمل نسخة احتياطية من قاعدة البيانات، امسحها، قم بإنشاء الجداول مرة أخرى (مع سيندسب، منذ الآن تقوم بإنشاء الجداول من الصفر) واستيراد البيانات التي تم الاحتفاظ بنسخة احتياطية منها (قد يستغرق ذلك وقتا طويلا إذا كانت قاعدة البيانات كبيرة)

أيه أفكار؟


إجراء يدويا التغييرات سكل وتفريغ / إعادة تحميل كلا الخيارين، ولكن قد تحتاج أيضا إلى التحقق من بعض حزم المخطط تطور جانغو. الخيارات الأكثر نضجا هي جانغو تطور وجنوب .

إديت : وهلا ، وهنا يأتي دميغراتيونس .

أوبديت : منذ أن كتبت هذه الإجابة في الأصل، جانغو تطور و دميغراشيونس على حد سواء توقفت التنمية النشطة وأصبح الجنوب المعيار الفعلي للهجرة مخطط في جانغو. قد يتم دمج أجزاء من الجنوب حتى في جانغو في الإصدار التالي أو اثنين.

تحديث : يتم تضمين إطار مخطط الهجرة على أساس جنوب (ومؤلف من قبل أندرو غودوين، مؤلف الجنوب) في جانغو 1.7+.


حتى الآن في شركتي استخدمنا النهج اليدوي. ما يعمل بشكل أفضل بالنسبة لك يعتمد كثيرا على نمط التنمية الخاص بك.

نحن عموما ليس لديها الكثير من التغييرات المخطط في نظم الإنتاج ولفائف رسمية إلى حد ما من التطوير إلى خوادم الإنتاج. كلما كنا طرح (10-20 مرات في السنة) ونحن نفعل ملء الاختلاف من الحالية وفريق الإنتاج القادم مراجعة كافة التعليمات البرمجية وملاحظة ما يجب أن تتغير على خادم الإنتاج. قد تكون التغييرات المطلوبة تبعيات إضافية، والتغييرات على ملف الإعدادات والتغييرات في قاعدة البيانات.

هذا يعمل بشكل جيد للغاية بالنسبة لنا. وجود كل ذلك الآلي هو رؤية المتخصصة ولكن لصعوبة بالنسبة لنا - ربما نتمكن من إدارة عمليات الهجرة ولكن ما زلنا بحاجة إلى التعامل مع مكتبة إضافية، خادم، أيا كان التبعيات.



لقد تم استخدام دجانغو تطور. وتشمل المحاذير ما يلي:

  • وكانت اقتراحاتها التلقائية فاسدة بشكل موحد؛ و
  • ترجع وظيفة بصمات الأصابع قيم مختلفة لقاعدة البيانات نفسها على منصات مختلفة.

ومع ذلك، أجد أن طريقة schema_evolution.py المخصصة في متناول اليد. للتغلب على مشكلة بصمة الإصبع، أقترح شفرة مثل:

BEFORE = 'fv1:-436177719' # first fingerprint
BEFORE64 = 'fv1:-108578349625146375' # same, but on 64-bit Linux
AFTER = 'fv1:-2132605944' 
AFTER64 = 'fv1:-3559032165562222486'

fingerprints = [
    BEFORE, AFTER,
    BEFORE64, AFTER64,
    ]

CHANGESQL = """
    /* put your SQL code to make the changes here */
    """

evolutions = [
    ((BEFORE, AFTER), CHANGESQL),
    ((BEFORE64, AFTER64), CHANGESQL)
    ]

إذا كان لي المزيد من بصمات الأصابع والتغييرات، وكنت إعادة عامل ذلك. حتى ذلك الحين، مما يجعل منظف سيكون سرقة الوقت اللازم للتطوير من شيء آخر.

إديت: نظرا لأنني أقوم بإنشاء تغييراتي يدويا على أي حال، سأحاول استخدام دميغراتيونس في المرة القادمة.


ويوضح كتاب جانغو كيفية القيام بذلك باليد.

http://www.djangobook.com/en/2.0/chapter10/

لقد فعلت ذلك بهذه الطريقة عدة مرات، وأنها مرنة جدا، مما يسمح لك لترك البيانات في الجداول أثناء إزالتها من النموذج.

لقد بدأت باستخدام الجنوب مؤخرا. يبدو قليلا أقل مرونة (أو ربما أنا فقط بحاجة لقراءة المستندات بعض أكثر). ولكن يمكن أن توفر لك قليلا من الكتابة. في بعض الأحيان كنت تدير للحصول على الخروج من التزامن مع قاعدة البيانات، وهو كابوس. يبدو أن تذهب على ما يرام طالما كنت الاستمرار في استخدام it.It لا يبدو لربط النماذج وقاعدة البيانات الفعلية معا، والتي قد أو قد لا تكون شيئا جيدا اعتمادا على الوضع الخاص بك


يقوم دجانغو 1.7 (قيد التطوير حاليا) بإضافة دعم أصلي manage.py migrate المخطط باستخدام manage.py migrate و manage.py makemigrations ( migrate يلغي syncdb ).







django