मेरे पास एक माइग्रेशन लिखा गया है जो मेरे परीक्षण डेटाबेस पर ठीक से निष्पादित होता है - क्या दर्जनों परीक्षण बिना किसी समस्या के चलते हैं। मैं इसे अपने प्रोड डेटाबेस के क्लोन पर चलाता हूं और अचानक मुझे सभी प्रकार की समस्याएं आ रही हैं। मुझे लगता है कि यह डेटाबेस कॉन्फ़िगरेशन या अनुमति समस्या है, लेकिन मैं इस क्लोन में रूट के रूप में लॉग इन हूं, इसलिए मुझे यह भी यकीन नहीं है कि कहां देखना शुरू करना है ...

Jika saya menyalin pernyataan MySQL dari kesalahan (... dan memperbaiki data yang hilang) pernyataan itu dijalankan tanpa masalah.

ALTER TABLE `retail_items-tmp_09-10-2020` CHANGE original_inventory initial_inventory INT DEFAULT NULL;

अपमानजनक रेखा:

Schema::table('retail_items-tmp_09-10-2020', function($table) {
     $table->renameColumn('original_inventory','initial_inventory');
});

त्रुटि:

[PDOException (42000)]
  SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '-tmp_09-10-2020 CHANGE original_inventory initial_inventory INT DEFAULT NULL' at line 1 

प्रवास:

    public function up()
      {
        /* 1. Backup Existing Tables */

          DB::statement('CREATE TABLE `retail_items-tmp_09-10-2020` LIKE `retail_items`; ');
          DB::statement('CREATE TABLE `ARCH__retail_items_09-10-2020` LIKE `retail_items`; ');

          DB::statement('INSERT INTO `retail_items-tmp_09-10-2020` SELECT * FROM `retail_items`; ');
          DB::statement('INSERT INTO `ARCH__retail_items_09-10-2020` SELECT * FROM `retail_items`;');

        /* 2. Update structure */

          Schema::table('retail_items-tmp_09-10-2020', function($table) {
            $table->renameColumn('original_inventory','initial_inventory');
          });

          Schema::table('retail_items-tmp_09-10-2020', function($table) {
            $table->integer('event_ID')->length(11)->unsigned()->nullable();
            $table->foreign('event_ID')->references('event_ID')->on('events');
          });


        /* 3. Update structure that would have been destructive prior to step 3 */


          // When I had this piece of code included, it resulted in the same error "Syntax error or access violation..." this worked in testing, but throws errors on Prod, changed to DB:statement below with success.
          // Schema::table('retail_items-tmp_09-10-2020', function($table) {
          //   $table->smallInteger('flag')->unsigned()->nullable(false)->default(0)->change();
          // });

          $query = "ALTER TABLE `retail_items-tmp_09-10-2020` CHANGE `flag` `flag` SMALLINT(11) DEFAULT 0 NOT NULL; ";
          DB::statement($query);
      }

मैं इस पर थोड़ी देर के लिए अटक गया हूं, इसलिए किसी भी सिद्धांत, देखने के लिए जगह इत्यादि की सराहना की जाएगी।

(Saya memiliki migrasi lain yang mengganti nama tabel temp di akhir ini. Saya memiliki beberapa migrasi dan operasi data yang bersama-sama mengambil ~ 10+ mnt untuk dieksekusi dengan potongan kode yang saya luncurkan dengan ini, jadi temp ini. Tabel diperlukan untuk mencegah downtime saat diluncurkan dalam produksi)

0
Kevin Foster 12 सितंबर 2020, 05:54

1 उत्तर

सबसे बढ़िया उत्तर

Saya masih akhirnya memiliki lebih banyak pemecahan masalah / hambatan lain pada masalah ini, jadi ini hanya menghapus satu ...

भले ही उन्हें ठीक से उद्धृत किया गया था, मैंने कई एस.ओ. विषय पर पोस्ट और जैसा कि वेबटेक्ट ने सुझाव दिया है कि मैंने केवल सभी को हटा दिया और डैश और चीजें बहुत अधिक लगातार और मज़बूती से काम करती थीं। मुझे अब भी लगता है कि यह एक रहस्य है कि क्यों ऐसा इसलिए हुआ क्योंकि मैंने पहले भी इस तरह की तिथियों में हाइफ़न का उपयोग किया है - ठीक से उद्धृत - बिना किसी समस्या के। लेकिन यह निश्चित रूप से मुझे एक पाश के लिए फेंक दिया। मुझे लगता है कि मैं आगे बढ़ने वाले दिनांक-तालिका-नामों में हाइफ़न का उपयोग करने के अभ्यास को पूरी तरह से बंद कर दूंगा। वे बेहतर पठनीयता वारंट की तुलना में अधिक सिरदर्द पैदा करते हैं।

0
Kevin Foster 2 अक्टूबर 2020, 23:43