Mysql: لا يمكن فحص قيمة خالية في سلسلة *

أعاد الرمز القديم قيمة []byte فارغة لقيم NULL مما جعل من المستحيل تمييز قيمة NULL عن سلسلة فارغة.
راجع المشكلة رقم 20 للحصول على التفاصيل.

تم إرجاع الخطأ بواسطة الحزمة database/sql بسبب هذا الهدف:

* Be flexible with type conversions, but be paranoid about silent
  truncation or other loss of precision.

يجب عليك استخدام http://golang.org/pkg/database/sql/#NullString إذا كان العمود قد يحتوي على قيم NULL

شكرا ، هذا منطقي.

أرغب تقريبًا في طريقة لتهيئة المكتبة لتعطيني السلوك القديم. من بعض النواحي ، فإن "القيمة الصفرية كقيمة افتراضية" لـ Go منطقية للغاية وتزيل الكثير من التعليمات البرمجية المعيارية. أود نوعًا ما أن أضع ذلك في مكان واحد ، بشكل قابل للتكوين ، بدلاً من نثره في كل مكان في الكود الخاص بي الذي قد أواجهه NULL. يعد استخدام NullString ، وما إلى ذلك ، أمرًا قبيحًا جدًا في التعليمات البرمجية.

NULL مجرد كابوس وأريد التخلص من NULLs. أعرّف صراحةً كل عمود في جداول _my_ على أنه ليس NULL ، ولكن أحيانًا يكون لأمر مثل SHOW PROCESSLIST NULL بداخله ، ولا يهتم الكود الخاص بي ؛ أريد سلسلة فارغة بدلاً من ذلك. سأستخدم NullString فقط ، وأتجاهل الخاصية الصالحة الخاصة بها ، واحصل فقط على سلسلة. ، والتي ستكون فارغة إذا كان العمود فارغًا.

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

أفضل أيضًا أن تتبع حزمة قاعدة البيانات / sql سياسة "القيمة الصفرية الافتراضية" الخاصة بـ Go. لا يزال بإمكانك التمييز بين أنواع Null * إذا كنت بحاجة إلى ذلك ، ولكن لسوء الحظ تم اتخاذ قرار التصميم بهذه الطريقة. ربما قاموا بتغييره في Go2 (+1 مني لذلك).
في الوقت الحالي ليس لدي أي خطة لإضافة خيار سائق لذلك. بالمقارنة مع PostgreSQL ، فإن البروتوكول بالفعل فوضى (صعب أفترض أنه أكثر كفاءة). لا أريد خلط السائق أكثر.
واحد str = nullStr.Value أكثر لكل سلسلة ممسوحة هو أهون الشرين في الوقت الحالي.

حاولت إضافة خيار إلى قيم صفر NULL : https://github.com/Go-SQL-Driver/MySQL/tree/zeroNULL
لكن هذا غير ممكن على مستوى السائق. إذا قمت بتعيين القيمة الصفرية على []byte{} يمكنك مسحها ضوئيًا إلى string و []byte ولكن ليس للأنواع العددية. إذا قمت بتعيينه على 0 ، يمكنك مسحه ضوئيًا لأنواع عددية ولكن تحصل على "0" كـ string / []byte .

لا أفهم تمامًا كيف يقوم السائق بالمسح ، ولكن بدلاً من ذلك
وضع dest [i] على شيء ما ، ماذا لو تخطى السائق الإعداد
Dest [i]؟

dest هو في الأساس شريحة []interface{} . القيمة الافتراضية لـ interface{} هي nil . لذا تخطي إعداد dest[i] له نفس نتيجة تعيين dest[i]=nil

لقد قمت بتحديث الفرع. يمكنك تجربتها بنفسك إذا أردت.

يبدو هذا مثاليًا لاحتياجاتي ، وسأجربه في المرة القادمة التي أقوم فيها بتحديث
نسخة من السائق.

جاء حل آخر إلى ذهني فقط:
فقط استخدم [] بايت بدلاً من السلسلة. تحويل nil - [] بايت ينتج سلسلة فارغة:

string([]byte(""))  // => ""
string([]byte(nil)) // => ""

http://play.golang.org/p/nivY1yBK3x

ربما احتفظ بهذا مفتوحًا ، وربما يكون جيدًا للأمثلة

الحل: https://github.com/guregu/null

نظرًا لأن هذه الصفحة لا تزال تظهر مرتفعًا نسبيًا في نتائج البحث ، فإن سنتي:

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

  SELECT
    id,
    COALESCE(name, '') as name
  FROM users

بهذه الطريقة ، إذا كان name يحتوي على NULL ، فسيتم استبداله بسلسلة فارغة عند المسح. يتم دعم الاندماج على نطاق واسع.

لا أفهم لماذا يطرح استثناء عندما تكون السلسلة فارغة

هذا المثال يعمل بالنسبة لي

يمكنك تمرير مؤشر سلسلة للتعامل معها كما يلي:

var txt *string
checkErr(result.Scan(&txt))
// do something with type *string

إنه يعمل بشكل جيد بالنسبة لي.

إلى جانب تعليق Dynom الرائع ، أعتقد أنه لا يزال من الجدير بالذكر أن النوع sql.NullString يكون مفيدًا إذا كنت تريد معالجة المشكلة في وجهة Scan (والتي أراها جانب Go) من مستوى تجريد قاعدة البيانات).

بالإضافة إلى ذلك ، فإنه يحافظ على القدرة على التمييز بين قيمة nil وسلسلة فارغة .

باستخدام nullstring ، يُطلب من المطوّر إنشاء خريطة vo إذا كنت تريد إظهار المعلومات مثل json على سبيل المثال. لا توجد مشكلة هنا ، هو نهج جيد وصحيح ولكنه ليس منطقيًا لجميع الحالات ، ثم يمكن أن يكون عملًا إضافيًا من خلال قيود اللغة.