פתיחת מסד נתונים בכל קריאה

[nigun]

@dovid
פה יש דיון ארוך בנושא
אבל לא הבנתי את המסקנא כ"כ
מישהו יכול לסכם את הדיון שם.

[dovid]

חשבתי שמפה כבר הבנת את המסקנא.
צור חיבור בכל מקם שאתה משתמש וסגור אותו מיידית.
זה מה שמוחלט גם שמה, ויש שמה עצה למקרים שבו רוצים לחסוך את זמן פתיחת החיבור מחדש ע"י הארכת משך הזמן שמאחורי הקלעים משאירים אותו חי.

[nigun]

@dovid
נראה לי שאני מפספס משהו לפי מה שאני מבין מכאן ומכאן
כשאני קורא לOPEN
זה לא פותח את המסד נתונים אלא פותח את הבריכה (pool בלע"ז)
והם מביאים דוגמא איך להקים שרת HTTP עם פתיחה אחת
כנראה שאני מפספס משהו
אבל עדיין לא הבנתי מה אני אמור לעשות.
נ.ב. סליחה אם אני מטרטר אותך לשווא

[dovid]

תפתח ותסגור כמו ילד טוב את המסד כל פעם וכל מקום שאתה משתמש בו.
בלי לחשוב/לדעת/להבין מה קורה (בינתיים)...
האם אתה מתקשה לעשות זאת? או שמשהו לא עובד כשורה?

[nigun]

@dovid
לא
אמנם זה דרש פקודת החלף קטנה, אבל זה לא נורא
אבל השאלה שלי מה נכון לעשות.
(למה שאני יגלה את עמצי תקוע עוד שנה בגלל שיש מידי הרבה חיבורים תקועים)

[dovid]

@nigun אז אני יכתוב ליתר בטחון שוב: זה בדיוק מה שהכי נכון לעשות.
אתה יכול ללכת בשמחה שאת הבעיה הזו פתרת בצורה הטובה ביותר! נקסט, לבעיות אחרות.

[יוסף בן שמעון]

@dovid חושבני שלא זו הכוונה, כשאתה פותח מאגר חיבורים מנוהל, אתה לא אמור לסגור אותו אחרי כל שאילתה, המאגר מנהל את יצירת החיבור וסגירתו.
אם הוא יסגור כל פעם את המאגר זה יצור עומס מיותר לחלוטין
לפי ההוראות בגיטהאב, וכך גם בלינק שהוא הביא מסטאק, צריך להגדיר משתנה גלובלי שמקבל את הערך מ sql.Open וזה מחזיק את המאגר המנוהל, מכאן ואילך הוא צריך לבקש מהמאגר חיבור פנוי ולתשאל אותו על ידי db.QueryRow וזהו

[dovid]

לא ביקשתי שייצור מאגר, אם ככה היה נשמע זה ראיה טובה לזה שאני לא מכיר את go.
מה שאמרתי שצריך להיות ככה
--פתיחת חיבור
----תשאול
--סגירת חיבור
כל מקום ומקום שבשימוש. לגבי הבזבוז שבסגירה יש את ניהול הpool שאמרתי בבטחון שהוא לבטח קיים בgo (שזה אומר שהחיבור לא נסגר ומתי שפותחים חיבור חדש בעצם ייעשה בו שימוש חוזר).
אני לא יודע איך בגו פותחים חיבור, ייתכן שזה אוטומטי כפי שאתה אומר אני לא יודע.
ממילא אם השאלה של @nigun זה מה לעשות תכלס אני יענה לעבור לC# כי אני לא מכיר go.

[יוסף בן שמעון]

@dovid אכן, עכשיו אני מבין שנכנסתי לסוגיא בראש של נוד, אם אתה עושה close אתה הורג את המאגר, צחוק הגורל שדוטנט השפה הכי עילית שרק עושים פווו ויש לך אפליקציה, דוקא הם לא טרחו להסתיר ממך את המימוש של סגירת חיבור והחזרתו למאגר, ואילו בנוד ובגו שלכאורה הרבה יותר "ברזליות", המימוש הזה מוסתר מעיני המפתח

[nigun]

@יוסף-בן-שמעון
אז מה אני אמור לעשות?

1. ליצור משתנה גלובלי
   2.לבצע פתיחה רק פעם אחת

[dovid]

@nigun תביא לי אתר שמסביר איך להשתמש בsql (עם דוגמאות עשירות ומפורטות ולא תיעוד) ואני אכתוב לך בדיוק מה לעשות.

[nigun]

@dovid
אלו טובים?
http://go-database-sql.org/accessing.html
https://www.alexedwards.net/blog/organising-database-access

[dovid]

@nigun כן.
לפי מה שכתוב לך אין לך בכלל פתיחת קונקשיין.
הdb.Open לא יוצר קונקשיין אלא סה"כ מקים מופע שנועד מטבעו להיות בעל חיים ארוכים ולא אמורים לסגרו (שם הוא סוגר אותו עם defer כשהתוכנית תיגמר). המופע הזה יכול להיות אחד לכל התוכנה כמו ש@יוסף-בן-שמעון אמר.
מה עם קונקשנים? זה נראה שמנהלים לך את זה מצויין מאחורי הקלעים (יש לזה חיסרון קצת כי אם אני מבין טוב אתה לא יכול להבטיח ששתי פקודות ירוצו על אותו קונקשיין) ובעצם כל קריאה לQuery מחזיקה קונקשיין שנסגר בrows.Close().
אז סיכמנו: var db *sql.DB אחד לכל האפליקציה.

[nigun]

שוב למדתי בדרך הקשה שצריך לקרוא דוקומנטיצות מהתחלה לסוף
בגלל שלא ידעתי בדיוק איך מתנהל הסשנים בGO
הגעתי מהר מאוד לSQL Error 1040: Too Many Connection
אחרי שקראתי את המדריך שהבאתי למעלה הייתי צריך לעשות שינויים גדולים בקוד בשביל לתקן את זה
(מזל שהרצתי בדיקת עומסים)

[יוסף בן שמעון]

@nigun פרט הרחב נמק

[nigun]

@יוסף-בן-שמעון
א. קראתי לבקשת INSERT עם Query ולא עם exec
כיוון שאני לא צריך את הפלט זה מבזבז נתונים, כי הוא יוצר פלט וזה משאיר את החיבור פתוח ליותר זמן
ב. במקרה של שגיאה עשיתי return בלי פקודה נוספת לrows.Close()
מה שגרם לחלק מהבקשות להישאר פתוח משום מה.
ולמדתי שמומלץ לזרוק הרבה Close כי אם לא יועיל לא יזיק
ג. למדתי שעדיף באופן כללי להכין את הבקשה עם Prepare ולעשות עליו כמה בקשות
(במקרה שלי כל בקשה נמצא בתוך פונקציה נפרדת כך שוויתרתי על זה כי זה מידי הרבה עבודה לבנות את כל הפונקציות מחדש)
ד. למדתי שאם בקשה אמורה לקבל רק שורה אחת משתמשים בQueryRow ולא בQuery
יש עוד כמה דברים שלא ירדתי לעומקם עדיין למשל ניהול ערכים רקים (NULL)

[dovid]

א. נראה לי שגוי לגמרי. הפלט הוא מספר קטן של 32 סיביות שזה כלום שבכלום, ובכל מקרה הקוד שלך מחכה לסיום הביצוע. המתאים בזה הוא QueryRow שהבאת בהמשך.
ב. תמיד תעשה defer rows.Close() שורה מתחת היצירה שלהם. ככה אין מצב שתפספס את הסגירה ותוותר לגמרי על הזריקה של הClose בכל מקום.

[nigun]

@dovid
אני לא יודע למה אבל כשהרצי מאות בקשות בלי לזרוק סגירה בכל מקום נתקעתי עם Too Many Connection
ועכשיו זה כבר לא קורה