קטגוריה: PostgreSQL

Sequel וPostgreSQL

לאחרונה אני מוצא את עצמי משתמש בתכונות מאוד מתקדמות של PostgreSQL, שחלקם נוספו רק ב9.2 (למשל range). העניין הוא שאני עובד עם רובי ו Sequel, ולרוב אנחנו שמים לב כי ORM אינם אוהבים דברים שהם לא סטנדרטיים.

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

ישנם שני דרכים לטעון תוספים:

  1. דרך גלובלית
  2. דרך שתופעל רק על החיבור שלנו

הדרך הגלובלית נראת כך:

Sequel.extension(:core_extensions, :pg_range, :pg_array)

הדרך של החיבור, נראת כך:

DB.extension(:pg_range, :pg_array)

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

DB[:readers].where(Sequel.pg_range(:comments_id).contains([10, 15, 1900])).sql
# SELECT * FROM "readers" WHERE ("comments_id" @> (10, 15, 1900))

והנה יש לנו שאילתא אשר משתמשת ב Range של Pg, אבל כתובה עם ORM.
בתעוד כתוב שגם שם השדה יכול להיות המקור של pg_range (למשל), אבל אצלי זה לא כך (גם אם זה גלובלי).

למערכים, הפעולה מאוד דומה גם כן:

DB[:comments].where(uid: 10).where(Sequel.pg_array_op(:comments).contains(Sequel.pg_array([15,23]))).sql
# SELECT * FROM "comments" WHERE (("id" = 1) AND ("comments" @> ARRAY[15,23]))

קריאה נוספת:

כשיש לך פטיש אוויר ביד …

לפני מספר חודשים עשיתי פרוייקט עם מישהו שהעסק שלו הוא פיתוח מערכות על wordpress.
הייתי צריך לבנות לו מערכת מבוססת טלפוניה לעסק שלו, עם ממשק ניהול למספר דברים, משהו כמו 3 מסכי ניהול, ובנוסף מספר ניתובים לשמור ולמשוך מידע.

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

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

שימוש בסינטרה מאפשר לי לקחת פריימוורק כדוגמת foundation או bootstrap כ css ובנוסף לשלב את ember/angular או סתם את jquery/dojo בהתאם לצורך.

עבור מסדי נתונים, אני גם מקבל גמישות, כך שאם חלילה וחס אני נאלץ לגעת ב MySQL/MariaDB (לרוב להתחבר למסד נתונים קיים) אין בעיה (לפחות ההתחברות, עם הגועל זה משהו אחר), ואם אני בר מזל ויכול לבחור מסד נתונים, אז אבחר ב PostgreSQL , ואם יש צורך אז אבחר בכלל במונגו או אולי בכלל בRedis ?

אם אני צריך, אז אוסיף למשל סוג של job queue בהתאם לצורך הספציפי והרשימה לעבודה עוד ארוכה…

כל אלו אינם קיימים בwp, היות ובתור cms הוא נועד לגישה מאוד מדוייקת שמתאימה ל cms, אבל לא אפליקצייה.

אבל כנראה גם הפעם מאסלו צדק, וכשיש  לך פטיש ביד, הכל נראה לך מסמר …