الحصول على مهمة dbdeploy الخاصة بـ Phing للتراجع تلقائيًا عن خطأ دلتا

Question

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

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

لذا فإن السؤال هو، هل هناك أي طريقة للحصول على معاملات استخدام dbdeploy أو هل يمكنك اقتراح أي طريقة أخرى لاستعادة phing تلقائيًا عند حدوث خطأ?

ملحوظة: أنا لست ماهرًا في استخدام Phing، لذلك إذا كان ذلك يتضمن كتابة مهمة مخصصة، فإن أي مثال للتعليمات البرمجية أو عنوان URL الذي يحتوي على مزيد من المعلومات سيكون محل تقدير كبير.شكرًا

Answer 1

(إذا كنت لا تزال هناك...) فيما يتعلق بمهمة phing لتفريغ قاعدة البيانات، استخدم الأداة المساعدة لتفريغ قاعدة البيانات وقم بإنشاء مهمة phing.أستخدم postgres بشكل أساسي ولدي هذا في ملف phing build.xml الخاص بي:

<target name="db-dump" depends="">
    <php expression="date('Ymd-Hi')" returnProperty="phing.dump.ts"/>
    <exec command="pg_dump -h ${db.host} -U ${db.user} -O ${db.name} | gzip > ${db.dumppath}/${db.name}-${phing.dump.ts}.gz" />
</target>

Answer 2

إن أبسط طريقة لحل مشكلتك هي استخدام مهمة pdoexec التي تقوم افتراضيًا بتشغيل البرنامج النصي SQL في المعاملة.عند حدوث خطأ، سيقوم محرك قاعدة البيانات تلقائيًا بالتراجع عن تغييراتك (حتى تلك الموجودة في جدول سجل التغيير - ستكون قاعدة البيانات في حالتها السابقة)

مثال:

<pdosqlexec 
    url="pgsql:host=${db.host}
    dbname=${db.name}"
    userid="${db.user}"
    password="${db.pass}"
    src="${build.dbdeploy.deployfile}"
/>

Answer 3

أعلم أن هذا موضوع قديم جدًا، ولكن ربما سيتم استخدامه بالكامل لشخص آخر.يمكنك استخدام عبارات محاولة->التقاط لتنفيذ حل لذلك.المثال الخاص بي :

<trycatch>
    <try>
        <exec
            command="${progs.mysql} -h${db.live.host} -u${db.live.user} -p${db.live.password} ${db.live.name} &lt; ${db.live.output}/${build.dbdeploy.deployfile}"
            dir="${project.basedir}"
            checkreturn="true" />
            <echo>Live  database was upgraded successfully</echo>
    </try>    
    <catch>
            <echo>Errors in upgrading database</echo>
            <exec
            command="${progs.mysql} -h${db.live.host} -u${db.live.user} -p${db.live.password} ${db.live.name} &lt; ${db.live.output}/${build.dbdeploy.undofile}"
            dir="${project.basedir}"
            checkreturn="true" />
    </catch>
    </trycatch>

Answer 4

لماذا لا تكتب سلسلة من دلتا التراجع وتضيف مهمة phing التي تعمل عند فشل المهمة الأخرى؟

Answer 5

يجب عليك حقا إلقاء نظرة على كابيسترانو.الطبل:أنت تفتقد شيئًا هنا:بالطبع يجب عمل نسخة احتياطية قبل تغيير المخطط - ولكن ماذا تفعل بالبيانات الجديدة التي تم إدراجها في الوقت الذي كنت تعتقد فيه أن كل شيء على ما يرام؟لا أقول أن هناك أداة جيدة لهذه المشكلة، لكن المشكلة موجودة في الحياة الواقعية.

Answer 6

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

أنت لا تقول ما هي قاعدة البيانات التي تستخدمها - ولكنني أتساءل عما إذا كان سيتم دعم جميع تغييرات المخطط في المعاملات.قواعد بيانات SQL الخاصة بموسم (Oracle، db2، sql server) لا تفعل ذلك في جميع الحالات لأسباب وجيهة حقًا.تعد تغييرات مخطط Transacitonal صعبة للغاية وتتطلب موارد مكثفة حقًا.