Mysql: توفير نوعي uint32 و uint64

تم إنشاؤها على ٢٨ نوفمبر ٢٠١٧ · 7تعليقات · مصدر: go-sql-driver/mysql

وصف المشكلة

عند استخدام نوع MySQL INT العادي كمفتاح أساسي ، يقوم المستخدمون عادةً بإنشاء نوع بـ INT UNSIGNED وهو 32b عدد صحيح. ومع ذلك ، لا يوجد مثل هذا النوع في حزمة db.sql الأساسية.

ناقشت هذا على reddit واقترح الجميع كتابة هذا النوع. ومع ذلك ، يبدو لي أن هذا يجب أن يكون في مكتبة ليتم إعادة استخدامها. أعتقد أنه يجب أن يكون في هذه المكتبة ، لأنه نوع خاص بـ MySQL (أحجام البايت) ولا أعتقد أنه يمكننا دفعه إلى حزمة db.sql.

أعتقد أن الهياكل يجب أن تمثل بشكل صحيح أنواع البيانات في MySQL لذلك لا توجد فيض ، والذي قد يحدث عند استخدام NullInt64 لحفظ البيانات في INT UNSIGNED . ينطبق الأمر نفسه عند استخدام BIGINT UNSIGNED - الذي لن تتناسب قيمته القصوى مع NullInt64.

مثال على الكود

type MyTable struct {
    ID uint
}

type MyOtherTable struct {
    ID uint
    MyTableID mysql.NullUint32 // Nullable relationship with MyTable
}

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

databassql issue enhancement question

مصدر

lunemec

👍1

التعليق الأكثر فائدة

arnehormann كان هناك نقاش حول هذا الأمر في Go database / sql package github ، حيث قال rsc إنه يجب إضافة هذا الدعم في برنامج تشغيل golang mysql على وجه التحديد (لأن قواعد البيانات لا تدعم هذه القيم الكبيرة).

انظر هنا: https://github.com/golang/go/issues/9373

lunemec في ١ ديسمبر ٢٠١٧

👍16

ال 7 كومينتر

نحن ملزمون بـ https://golang.org/pkg/database/sql/driver/#Value - ويتواصل السائق مع قاعدة البيانات / sql ضمن هذه القيود. باستثناء NullTime الذي كان مفقودًا في database / sql ، لن نضيف أنواعًا إضافية.

arnehormann في ٢٩ نوفمبر ٢٠١٧

انظر هنا: https://github.com/golang/go/issues/9373

lunemec في ١ ديسمبر ٢٠١٧

👍16

نعم ، كتب:
`` هناك قواعد بيانات (على سبيل المثال sqlite) لا تدعم مثل هذه القيم الكبيرة.
هذا هو السبب في أن قاعدة البيانات / SQL لا تسمح بذلك افتراضيًا.
لا يمكننا تغيير هذا القرار الآن ، لأنه سيكسر جميع الدوافع الحالية.

إذا كانت MySQL تدعم مثل هذه القيم الكبيرة ، فيمكن لبرنامج تشغيل MySQL إنشاء ملفات
تنفيذ driver.Stmt تنفيذ driver.ColumnConverter والسماح
uint64s في ValueConverter مخصص.

أي أن برنامج تشغيل MySQL الذي يريد السماح لـ uint64s الكبيرة يمكنه القيام بذلك اليوم.
ليس هناك حاجة لتغيير التعليمات البرمجية في قاعدة البيانات / SQL.
""

أوافق على أن هذا مطلوب ، والأهم من ذلك بالنسبة لـ uint32 بدلاً من uint64 ، لأن uint64 أقل احتمالاً للتجاوز في أي وقت قريبًا.
كيف يمكننا تحقيق ذلك؟ أنا على استعداد للمساعدة في إنشاء طلب سحب لهذا الغرض.

mastertheknife في ٢٢ سبتمبر ٢٠٢٠

نحن بالفعل ندعم uint64.

methane في ٢٣ سبتمبر ٢٠٢٠

نحن بالفعل ندعم uint64.

ولكن ليس NullUint64 ، والذي يجب استخدامه لحقل BIGINT UNSIGNED nullable.
تحتاج إلى استخدام NullInt64 بدلاً من ذلك ، والذي يمكن أن يؤدي إلى تجاوز السعة.

mastertheknife في ٢٣ سبتمبر ٢٠٢٠

لقد ذكرت تعليق rsc حول uint64 لذلك أجبت أنه تم تنفيذه بالفعل كما اقترح rsc.
إذا كنت تقترح NullUint64 بدلاً من uint64 ، فقل ذلك دون ذكر تعليق rsc. إنه محير فقط.

methane في ٢٣ سبتمبر ٢٠٢٠

نحن بالفعل ندعم uint64.
ولكن ليس NullUint64 ، والذي يجب استخدامه لحقل BIGINT UNSIGNED nullable.
تحتاج إلى استخدام NullInt64 بدلاً من ذلك ، والذي يمكن أن يؤدي إلى تجاوز السعة.

لقد أنشأت حزمة تحل هذا النوع من المشاكل

https://github.com/Thor-x86/nullable