הצעת ייעול | עדכונים במסד של זית שעוד לא נכנסו למסד של אוצריא
-
שמתי לב שנכנסו שינויים לאחרונה בזית שעוד לא הגיעו למסד של אוצריא הדבר נוגע בעיקר לתיוג של סוגי המפרשים
אינני יודע מי אחראי על זה אז עשיתי פוסט כללי
זה קצת משפיע על כתבי הקודש משום מה זה גורם לאיטיות בטעינת המפרשים
אני לא אומר שזה בעיה של אוצריא רק שכך שמתי לב לעניין@pcinfogmach
זה אמור להיות בטיפול של @י.-פל.
אבל הוא מחכה למספר שיפורים שייכנסו או לא יכנסו גם למסד של זית, שאוצריא זקוקה להם. -
@pcinfogmach
זה אמור להיות בטיפול של @י.-פל.
אבל הוא מחכה למספר שיפורים שייכנסו או לא יכנסו גם למסד של זית, שאוצריא זקוקה להם.הייתי שמח אם תפרטו קצת כי כרגע כל שינוי שנכנס לזית אני צריך "לעלות" עליו אז אם יש לכם פרטים להיכן המגמה זה מאוד יקל עלי
-
@י.-פל.
לאחר בדיקת הנושא, מצאתי הבדל ספציפי שעשוי להיות רלוונטי. אני מציין זאת משום שלא הייתי מודע כלל לקיומם של אינדקסים משולבים ב־SQLite, ולכן זה פרט שקל לפספס.בזית קיימת בטבלת הקישורים (
link) הגדרת אינדקס משולב על השדותconnectionTypeIdו־targetLineId, בעוד שבאוצריא אינדקס כזה אינו קיים.המשמעות עשויה להיות חשובה במיוחד משום שבגרסאות האחרונות זית הפסיק לציין במפורש קישורים מסוג "מקור", וכדי לשלוף אותם מתבצע חיפוש הפוך.
ללא אינדקס משולב, SQLite יכול להשתמש רק באחד מהאינדקסים הקיימים ולאחר מכן לסרוק ולסנן את התוצאות לפי התנאי השני. לעומת זאת, אינדקס משולב מאפשר לאתר ישירות את הרשומות שעונות על שני התנאים יחד, ובכך מצמצם סריקות מיותרות ועשוי לשפר משמעותית את ביצועי השאילתות הללו.
-
@י.-פל.
לאחר בדיקת הנושא, מצאתי הבדל ספציפי שעשוי להיות רלוונטי. אני מציין זאת משום שלא הייתי מודע כלל לקיומם של אינדקסים משולבים ב־SQLite, ולכן זה פרט שקל לפספס.בזית קיימת בטבלת הקישורים (
link) הגדרת אינדקס משולב על השדותconnectionTypeIdו־targetLineId, בעוד שבאוצריא אינדקס כזה אינו קיים.המשמעות עשויה להיות חשובה במיוחד משום שבגרסאות האחרונות זית הפסיק לציין במפורש קישורים מסוג "מקור", וכדי לשלוף אותם מתבצע חיפוש הפוך.
ללא אינדקס משולב, SQLite יכול להשתמש רק באחד מהאינדקסים הקיימים ולאחר מכן לסרוק ולסנן את התוצאות לפי התנאי השני. לעומת זאת, אינדקס משולב מאפשר לאתר ישירות את הרשומות שעונות על שני התנאים יחד, ובכך מצמצם סריקות מיותרות ועשוי לשפר משמעותית את ביצועי השאילתות הללו.
ללא אינדקס משולב, SQLite יכול להשתמש רק באחד מהאינדקסים הקיימים ולאחר מכן לסרוק ולסנן את התוצאות לפי התנאי השני. לעומת זאת, אינדקס משולב מאפשר לאתר ישירות את הרשומות שעונות על שני התנאים יחד, ובכך מצמצם סריקות מיותרות ועשוי לשפר משמעותית את ביצועי השאילתות הללו.
קשור גם לעניין של שני אינדקסים - האינדקס של הספרייה והאינדקס של הספרים האישיים?
-
@י.-פל.
לאחר בדיקת הנושא, מצאתי הבדל ספציפי שעשוי להיות רלוונטי. אני מציין זאת משום שלא הייתי מודע כלל לקיומם של אינדקסים משולבים ב־SQLite, ולכן זה פרט שקל לפספס.בזית קיימת בטבלת הקישורים (
link) הגדרת אינדקס משולב על השדותconnectionTypeIdו־targetLineId, בעוד שבאוצריא אינדקס כזה אינו קיים.המשמעות עשויה להיות חשובה במיוחד משום שבגרסאות האחרונות זית הפסיק לציין במפורש קישורים מסוג "מקור", וכדי לשלוף אותם מתבצע חיפוש הפוך.
ללא אינדקס משולב, SQLite יכול להשתמש רק באחד מהאינדקסים הקיימים ולאחר מכן לסרוק ולסנן את התוצאות לפי התנאי השני. לעומת זאת, אינדקס משולב מאפשר לאתר ישירות את הרשומות שעונות על שני התנאים יחד, ובכך מצמצם סריקות מיותרות ועשוי לשפר משמעותית את ביצועי השאילתות הללו.
@pcinfogmach
אני חושב שזה בנוי כל כך שהוא צמצם את כל הקישורים מלהכיל את שתי הכיוונים - להכיל כיוון אחד בלבד ולשלוף אותו פעמיים. -
ללא אינדקס משולב, SQLite יכול להשתמש רק באחד מהאינדקסים הקיימים ולאחר מכן לסרוק ולסנן את התוצאות לפי התנאי השני. לעומת זאת, אינדקס משולב מאפשר לאתר ישירות את הרשומות שעונות על שני התנאים יחד, ובכך מצמצם סריקות מיותרות ועשוי לשפר משמעותית את ביצועי השאילתות הללו.
קשור גם לעניין של שני אינדקסים - האינדקס של הספרייה והאינדקס של הספרים האישיים?
@יאיר-דניאל
אין לזה קשר לאינדקס החיפוש. -
@pcinfogmach
אני חושב שזה בנוי כל כך שהוא צמצם את כל הקישורים מלהכיל את שתי הכיוונים - להכיל כיוון אחד בלבד ולשלוף אותו פעמיים.@pcinfogmach
אני חושב שזה בנוי כל כך שהוא צמצם את כל הקישורים מלהכיל את שתי הכיוונים - להכיל כיוון אחד בלבד ולשלוף אותו פעמיים.כן. למיטב זכרוני הוא כתב על כך מפורש לא מזמן.
-
@יאיר-דניאל
אין לזה קשר לאינדקס החיפוש.@הבל-הבלים אני לא מדבר על אינדקס חיפוש - אלא על שני קבצי הDB.
-
@הבל-הבלים אני לא מדבר על אינדקס חיפוש - אלא על שני קבצי הDB.
-
@pcinfogmach
אני חושב שזה בנוי כל כך שהוא צמצם את כל הקישורים מלהכיל את שתי הכיוונים - להכיל כיוון אחד בלבד ולשלוף אותו פעמיים.כן. למיטב זכרוני הוא כתב על כך מפורש לא מזמן.
כן. למיטב זכרוני הוא כתב על כך מפורש לא מזמן.
איפה?
מאוד הייתי שמח לדעת איפה הוא כותב על הדברים הללו -
כן. למיטב זכרוני הוא כתב על כך מפורש לא מזמן.
איפה?
מאוד הייתי שמח לדעת איפה הוא כותב על הדברים הללו@pcinfogmach אני אבדוק. לא זוכר כרגע, אבל נראה לי זה היה בפורום פה.
בכ"א אנסה למצוא את זה. -
@יאיר-דניאל
תסביר.@הבל-הבלים
@pcinfogmach כתב בנושא שנפתח על הבעיות שיש - אם יש בכלי קודש בשימוש בDB של אוצריא, שיש בעיה עם הספרים האישיים, כיון שאוצריא יוצרת להם DB נפרד, וכלי קודש לא תומכת בשני DB במקביל.לכן שאלתי, האם לאחר שהוא יפתור את העניין של תמיכה בשני אינדקסים במקביל, האם זה יוכל בדרך כל שהיא לפתור את העניין של התמיכה בשני DB במקביל.
יכול להיות שאני פשוט מדבר שטויות במיץ, כי ההתעסקות היחידה של עם SQLite הייתה בתוכנה שלי של הPDF שפיתחתי, וזה כלל יותר הוראות לAI מאשר שינויים ידניים...
-
@הבל-הבלים
@pcinfogmach כתב בנושא שנפתח על הבעיות שיש - אם יש בכלי קודש בשימוש בDB של אוצריא, שיש בעיה עם הספרים האישיים, כיון שאוצריא יוצרת להם DB נפרד, וכלי קודש לא תומכת בשני DB במקביל.לכן שאלתי, האם לאחר שהוא יפתור את העניין של תמיכה בשני אינדקסים במקביל, האם זה יוכל בדרך כל שהיא לפתור את העניין של התמיכה בשני DB במקביל.
יכול להיות שאני פשוט מדבר שטויות במיץ, כי ההתעסקות היחידה של עם SQLite הייתה בתוכנה שלי של הPDF שפיתחתי, וזה כלל יותר הוראות לAI מאשר שינויים ידניים...
@יאיר-דניאל
למיטב ידיעתי - אין שום קשר. -
כן. למיטב זכרוני הוא כתב על כך מפורש לא מזמן.
איפה?
מאוד הייתי שמח לדעת איפה הוא כותב על הדברים הללוכן. למיטב זכרוני הוא כתב על כך מפורש לא מזמן.
איפה?
מאוד הייתי שמח לדעת איפה הוא כותב על הדברים הללומה שמצאתי כרגע הוא זה:
https://otzaria.org/forum/post/9073
עיין מפוסט זה ואילך מה שהוא הגיב וכתב, אבל מרפרוף כעת - כתוב שם להיפך, שהם עשו טבלה אחת - לא שתיים. -
@pcinfogmach @יאיר-דניאל אני לא כ"כ מבין את כל המשפטים שנכתבו כאן אבל כמדומה שאתם מתכוונים לזה, אכן ?
https://otzaria.org/forum/topic/991/הסבר-מפרשים-לא-קשורים/34 -
@pcinfogmach @יאיר-דניאל אני לא כ"כ מבין את כל המשפטים שנכתבו כאן אבל כמדומה שאתם מתכוונים לזה, אכן ?
https://otzaria.org/forum/topic/991/הסבר-מפרשים-לא-קשורים/34@pcinfogmach @יאיר-דניאל אני לא כ"כ מבין את כל המשפטים שנכתבו כאן אבל כמדומה שאתם מתכוונים לזה, אכן ?
https://otzaria.org/forum/topic/991/הסבר-מפרשים-לא-קשורים/34מדוייק!
דיברתי איתו עכשיו בטלפון במקרה וזה בדיוק מה שהוא אמר לי.אבל @ pcinfogmach
מחפש מה @ elie-gambache כתב על זה -
@הבל-הבלים
@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, ומה שיעניין אותך - הוא היה אמור ליישם (הוא החליט לדחות את זה לאח״כ - כנראה החיפוש כיף לו יותר) קישורים למילה בשורה, ולא רק לשורה.
זה הגיע בעקבות הכנסת השעה״צ על ידינו, ובמקום ליצור גנרטור יחודי, הוא החליט ללכת על גדול (כדרכו!), ולעשות משהו מקיף יותר, כך שכלל המפרשים הזמינים ירוויחו - למשל באה״ג.
שלום! נראה שהשיחה הזו מעניינת אותך, אבל עדיין אין לך חשבון.
נמאס לכם לגלול בין אותם הפוסטים בכל ביקור? כשנרשמים לחשבון, תמיד תחזרו בדיוק למקום שבו הייתם קודם, ותוכלו לבחור לקבל התראות על תגובות חדשות (בין אם במייל, ובין אם בהתראת פוש). תוכלו גם לשמור סימניות ולפרגן ב-upvote לפוסטים כדי להביע הערכה לחברי קהילה אחרים.
בעזרת התרומה שלך, הפוסט הזה יכול להיות אפילו טוב יותר 💗
הרשמה התחברות