הצעת ייעול | עדכונים במסד של זית שעוד לא נכנסו למסד של אוצריא
-
@הבל-הבלים
@pcinfogmach כתב בנושא שנפתח על הבעיות שיש - אם יש בכלי קודש בשימוש בDB של אוצריא, שיש בעיה עם הספרים האישיים, כיון שאוצריא יוצרת להם DB נפרד, וכלי קודש לא תומכת בשני DB במקביל.לכן שאלתי, האם לאחר שהוא יפתור את העניין של תמיכה בשני אינדקסים במקביל, האם זה יוכל בדרך כל שהיא לפתור את העניין של התמיכה בשני DB במקביל.
יכול להיות שאני פשוט מדבר שטויות במיץ, כי ההתעסקות היחידה של עם SQLite הייתה בתוכנה שלי של הPDF שפיתחתי, וזה כלל יותר הוראות לAI מאשר שינויים ידניים...
יכול להיות שאני פשוט מדבר שטויות במיץ, כי ההתעסקות היחידה של עם SQLite הייתה בתוכנה שלי של הPDF שפיתחתי, וזה כלל יותר הוראות לAI מאשר שינויים ידניים...
הסבר על רגל אחת
sqlite בצורה מופשטת זה פשוט טבלאות בכל טבלה יש עמודות ממש כמו טבלת אקסל.
אינדקס זה אומר שעמודה מוגדרת כמפתח וsqlite בונה לזה אינדקס מה שמאפשר שליפת נתוני מדוייקת ומהירה יותר.
אינדקס משולב זה אומר ששני עמודות משולבים לתוך אינדקס אחד כלומר כל מופע באינדקס בנוי משני ערכים אחד מכל עמודה מה שמפאשר למקד עוד יותר.
זה הכלל ממוקד יותר = מהר יותר. -
@י.-פל.
לאחר בדיקת הנושא, מצאתי הבדל ספציפי שעשוי להיות רלוונטי. אני מציין זאת משום שלא הייתי מודע כלל לקיומם של אינדקסים משולבים ב־SQLite, ולכן זה פרט שקל לפספס.בזית קיימת בטבלת הקישורים (
link) הגדרת אינדקס משולב על השדותconnectionTypeIdו־targetLineId, בעוד שבאוצריא אינדקס כזה אינו קיים.המשמעות עשויה להיות חשובה במיוחד משום שבגרסאות האחרונות זית הפסיק לציין במפורש קישורים מסוג "מקור", וכדי לשלוף אותם מתבצע חיפוש הפוך.
ללא אינדקס משולב, SQLite יכול להשתמש רק באחד מהאינדקסים הקיימים ולאחר מכן לסרוק ולסנן את התוצאות לפי התנאי השני. לעומת זאת, אינדקס משולב מאפשר לאתר ישירות את הרשומות שעונות על שני התנאים יחד, ובכך מצמצם סריקות מיותרות ועשוי לשפר משמעותית את ביצועי השאילתות הללו.
@י.-פל.
לאחר בדיקת הנושא, מצאתי הבדל ספציפי שעשוי להיות רלוונטי. אני מציין זאת משום שלא הייתי מודע כלל לקיומם של אינדקסים משולבים ב־SQLite, ולכן זה פרט שקל לפספס.בזית קיימת בטבלת הקישורים (
link) הגדרת אינדקס משולב על השדותconnectionTypeIdו־targetLineId, בעוד שבאוצריא אינדקס כזה אינו קיים.המשמעות עשויה להיות חשובה במיוחד משום שבגרסאות האחרונות זית הפסיק לציין במפורש קישורים מסוג "מקור", וכדי לשלוף אותם מתבצע חיפוש הפוך.
ללא אינדקס משולב, SQLite יכול להשתמש רק באחד מהאינדקסים הקיימים ולאחר מכן לסרוק ולסנן את התוצאות לפי התנאי השני. לעומת זאת, אינדקס משולב מאפשר לאתר ישירות את הרשומות שעונות על שני התנאים יחד, ובכך מצמצם סריקות מיותרות ועשוי לשפר משמעותית את ביצועי השאילתות הללו.
ai? סתם סקרנות...
הייתי שמח אם תפרטו קצת כי כרגע כל שינוי שנכנס לזית אני צריך "לעלות" עליו אז אם יש לכם פרטים להיכן המגמה זה מאוד יקל עלי
אגיב ל2 הפוסטים יחד.
כפי כתבתי בקיצור בפוסט ש @חד-צורבא הביא, בזית בגרסא הקודמת, ובאוצריא עדיין (היום התחלתי טסטים וסיומים לdb החדש) - כל קישור היה כפול: פעם אחת כsource ופעם אחת כtarget, כך ש - למשל - רשי על בראשית א,א היה מוצג פעמיים: הפעם הראשונה הוא היה הtarget (כמפרש) ופעם אחת כsource - כשהחומש הוא הtarget.
בשביל שאוצריא תוכל להכניס לינקים גם לחומש עצמו - ולכל ספר שנכנס בגנרטור של ספריא, היו 2 אפשרויות: או להתערב בגנרטור, או - כפי שבוצע למעשה - לחתוך את הקישורים ל2 (דבר שגם חסך די הרבה מקום), ואת ההמרה לפרשן/מקור/תרגום לעשות בתוכנה.
זה, בעצם, ההתחלה של קישור ספרי אוצריא למקורותיהם ( @צדיק-וטוב-לו אולי סוף סוף תבין למה כל שבוע אני כותב לך עוד מעט
).כמובן שמי יעמוד בסוד קדושים, ואני לא יודע מה התוכניות של לא מתייאש, אני כן יודע שכעת הוא מתמקד בחיפוש וai, ומה שיעניין אותך - הוא היה אמור ליישם (הוא החליט לדחות את זה לאח״כ - כנראה החיפוש כיף לו יותר) קישורים למילה בשורה, ולא רק לשורה.
זה הגיע בעקבות הכנסת השעה״צ על ידינו, ובמקום ליצור גנרטור יחודי, הוא החליט ללכת על גדול (כדרכו!), ולעשות משהו מקיף יותר, כך שכלל המפרשים הזמינים ירוויחו - למשל באה״ג. -
@י.-פל.
לאחר בדיקת הנושא, מצאתי הבדל ספציפי שעשוי להיות רלוונטי. אני מציין זאת משום שלא הייתי מודע כלל לקיומם של אינדקסים משולבים ב־SQLite, ולכן זה פרט שקל לפספס.בזית קיימת בטבלת הקישורים (
link) הגדרת אינדקס משולב על השדותconnectionTypeIdו־targetLineId, בעוד שבאוצריא אינדקס כזה אינו קיים.המשמעות עשויה להיות חשובה במיוחד משום שבגרסאות האחרונות זית הפסיק לציין במפורש קישורים מסוג "מקור", וכדי לשלוף אותם מתבצע חיפוש הפוך.
ללא אינדקס משולב, SQLite יכול להשתמש רק באחד מהאינדקסים הקיימים ולאחר מכן לסרוק ולסנן את התוצאות לפי התנאי השני. לעומת זאת, אינדקס משולב מאפשר לאתר ישירות את הרשומות שעונות על שני התנאים יחד, ובכך מצמצם סריקות מיותרות ועשוי לשפר משמעותית את ביצועי השאילתות הללו.
ai? סתם סקרנות...
הייתי שמח אם תפרטו קצת כי כרגע כל שינוי שנכנס לזית אני צריך "לעלות" עליו אז אם יש לכם פרטים להיכן המגמה זה מאוד יקל עלי
אגיב ל2 הפוסטים יחד.
כפי כתבתי בקיצור בפוסט ש @חד-צורבא הביא, בזית בגרסא הקודמת, ובאוצריא עדיין (היום התחלתי טסטים וסיומים לdb החדש) - כל קישור היה כפול: פעם אחת כsource ופעם אחת כtarget, כך ש - למשל - רשי על בראשית א,א היה מוצג פעמיים: הפעם הראשונה הוא היה הtarget (כמפרש) ופעם אחת כsource - כשהחומש הוא הtarget.
בשביל שאוצריא תוכל להכניס לינקים גם לחומש עצמו - ולכל ספר שנכנס בגנרטור של ספריא, היו 2 אפשרויות: או להתערב בגנרטור, או - כפי שבוצע למעשה - לחתוך את הקישורים ל2 (דבר שגם חסך די הרבה מקום), ואת ההמרה לפרשן/מקור/תרגום לעשות בתוכנה.
זה, בעצם, ההתחלה של קישור ספרי אוצריא למקורותיהם ( @צדיק-וטוב-לו אולי סוף סוף תבין למה כל שבוע אני כותב לך עוד מעט ).כמובן שמי יעמוד בסוד קדושים, ואני לא יודע מה התוכניות של לא מתייאש, אני כן יודע שכעת הוא מתמקד בחיפוש וai, ומה שיעניין אותך - הוא היה אמור ליישם (הוא החליט לדחות את זה לאח״כ - כנראה החיפוש כיף לו יותר) קישורים למילה בשורה, ולא רק לשורה.
זה הגיע בעקבות הכנסת השעה״צ על ידינו, ובמקום ליצור גנרטור יחודי, הוא החליט ללכת על גדול (כדרכו!), ולעשות משהו מקיף יותר, כך שכלל המפרשים הזמינים ירוויחו - למשל באה״ג. -
@י.-פל.
לאחר בדיקת הנושא, מצאתי הבדל ספציפי שעשוי להיות רלוונטי. אני מציין זאת משום שלא הייתי מודע כלל לקיומם של אינדקסים משולבים ב־SQLite, ולכן זה פרט שקל לפספס.בזית קיימת בטבלת הקישורים (
link) הגדרת אינדקס משולב על השדותconnectionTypeIdו־targetLineId, בעוד שבאוצריא אינדקס כזה אינו קיים.המשמעות עשויה להיות חשובה במיוחד משום שבגרסאות האחרונות זית הפסיק לציין במפורש קישורים מסוג "מקור", וכדי לשלוף אותם מתבצע חיפוש הפוך.
ללא אינדקס משולב, SQLite יכול להשתמש רק באחד מהאינדקסים הקיימים ולאחר מכן לסרוק ולסנן את התוצאות לפי התנאי השני. לעומת זאת, אינדקס משולב מאפשר לאתר ישירות את הרשומות שעונות על שני התנאים יחד, ובכך מצמצם סריקות מיותרות ועשוי לשפר משמעותית את ביצועי השאילתות הללו.
ai? סתם סקרנות...
הייתי שמח אם תפרטו קצת כי כרגע כל שינוי שנכנס לזית אני צריך "לעלות" עליו אז אם יש לכם פרטים להיכן המגמה זה מאוד יקל עלי
אגיב ל2 הפוסטים יחד.
כפי כתבתי בקיצור בפוסט ש @חד-צורבא הביא, בזית בגרסא הקודמת, ובאוצריא עדיין (היום התחלתי טסטים וסיומים לdb החדש) - כל קישור היה כפול: פעם אחת כsource ופעם אחת כtarget, כך ש - למשל - רשי על בראשית א,א היה מוצג פעמיים: הפעם הראשונה הוא היה הtarget (כמפרש) ופעם אחת כsource - כשהחומש הוא הtarget.
בשביל שאוצריא תוכל להכניס לינקים גם לחומש עצמו - ולכל ספר שנכנס בגנרטור של ספריא, היו 2 אפשרויות: או להתערב בגנרטור, או - כפי שבוצע למעשה - לחתוך את הקישורים ל2 (דבר שגם חסך די הרבה מקום), ואת ההמרה לפרשן/מקור/תרגום לעשות בתוכנה.
זה, בעצם, ההתחלה של קישור ספרי אוצריא למקורותיהם ( @צדיק-וטוב-לו אולי סוף סוף תבין למה כל שבוע אני כותב לך עוד מעט ).כמובן שמי יעמוד בסוד קדושים, ואני לא יודע מה התוכניות של לא מתייאש, אני כן יודע שכעת הוא מתמקד בחיפוש וai, ומה שיעניין אותך - הוא היה אמור ליישם (הוא החליט לדחות את זה לאח״כ - כנראה החיפוש כיף לו יותר) קישורים למילה בשורה, ולא רק לשורה.
זה הגיע בעקבות הכנסת השעה״צ על ידינו, ובמקום ליצור גנרטור יחודי, הוא החליט ללכת על גדול (כדרכו!), ולעשות משהו מקיף יותר, כך שכלל המפרשים הזמינים ירוויחו - למשל באה״ג. -
@י.פ.ל
נ.ב נוספו בזית עוד סוגי קישורים עיין בטבלת connection type@pcinfogmach אם מעניין אותך כל סוגי הקישורים שקיימים, נכון ללפני תקופה זה אלו:
""
"None"
"allusion"
"commentary"
"dibur_hamatchil"
"ein mishpat"
"ein mishpat / ner mitsvah"
"explication"
"footnotes"
"law"
"linker"
"liturgy"
"mesorat hashas"
"midrash"
"mishnah in talmud"
"none"
"parshanut"
"quotation"
"quotation_auto"
"quotation_auto_tanakh"
"reference"
"related"
"related passage"
"sifrei mitzvot"
"summary"
"super_commentary"
"targum" -
זה נראה אשכול לדוברי רוסית בלבד...
-
@pcinfogmach אם מעניין אותך כל סוגי הקישורים שקיימים, נכון ללפני תקופה זה אלו:
""
"None"
"allusion"
"commentary"
"dibur_hamatchil"
"ein mishpat"
"ein mishpat / ner mitsvah"
"explication"
"footnotes"
"law"
"linker"
"liturgy"
"mesorat hashas"
"midrash"
"mishnah in talmud"
"none"
"parshanut"
"quotation"
"quotation_auto"
"quotation_auto_tanakh"
"reference"
"related"
"related passage"
"sifrei mitzvot"
"summary"
"super_commentary"
"targum"@יום-חדש-מתחיל
ב-db הנוכחי יש הרבה פחות כנראה זה משהו עתידי או משהו בספריא שלא נכנס למסד של זית -
@יום-חדש-מתחיל
ב-db הנוכחי יש הרבה פחות כנראה זה משהו עתידי או משהו בספריא שלא נכנס למסד של זית
שלום! נראה שהשיחה הזו מעניינת אותך, אבל עדיין אין לך חשבון.
נמאס לכם לגלול בין אותם הפוסטים בכל ביקור? כשנרשמים לחשבון, תמיד תחזרו בדיוק למקום שבו הייתם קודם, ותוכלו לבחור לקבל התראות על תגובות חדשות (בין אם במייל, ובין אם בהתראת פוש). תוכלו גם לשמור סימניות ולפרגן ב-upvote לפוסטים כדי להביע הערכה לחברי קהילה אחרים.
בעזרת התרומה שלך, הפוסט הזה יכול להיות אפילו טוב יותר 💗
הרשמה התחברות