ساختار کلید about cal-events

[fzerorubigd]

من پیشنهاد رو رد نکردم. منتها این مورد به خصوص یه چیزیه که تا آخر باهاش گیر میکنیم :) شاید بد نباشه یکم به آپشنهای مختلف فکر کنیم.

پیشنهاد من اینه که یه کلید درست کنیم توی فایل یمل اصلی، بعد اون کلید اینجوری باشه

partial_key: a_string_unique_in_this_month_in_english
# Example 
partial_key: nowrouz

وقت پابلیش نهایی میشه این تو فایل اصلی :

key: jalali_0101_nowrouz

یعنی یه بخشش ساخته میشه و یه بخشش بر مبنای ورودیه.

[fzerorubigd]

محدودیت رو بهتره براش بذاریم. اگه کسی بخواد این دیتا رو ببره تو یه دیتابیس و استفاده کنه قطعا به مشکل میخوره با دیتای خیلی بلند. البته راه ساده ترش هم اینه که از مثلا siphash استفاده کنیم و کلید نهایی (تو فایل dist و نه توی فایلهایی که ما مدیریتش میکنیم ) رو بذاریم هش کلید ما (ترکیب همه اون آیتمها با هم) اینجوری محدودیت سایز هم حذف میشه

[fzerorubigd]

پیشنهادم همچین چیزیه که الان تو این PR فرستادم. کلید نهایی بر اساس کلید داده شده جنریت میشه و همیشه یک عدد ۶۴ بیتیه که تا زمانی که کلید رویداد عوض نشه اینم عوض نمیشه

[fzerorubigd]

بحث اشتباه اون چیزیه که اختیاری فرضش کردی. حضورش توی ترتیب تاثیر میذاره. یعنی اول رویدادهای بی سال میان، بعد رویدادهای با سال، به ترتیب سال صعودی.

بزرگترین مشکل این روش اینه که اگه بخوایم یه رویداد رو منتقل کنیم نمیشه. بر فرض یه روزی بخوای کل رویدادهای ایران اسلامی رو بفرستی تو یه تقویم دیگه. 😉 ولی رویدادهای ایران باستانی مثلا سر جاشونن و یه سری رویداد جدید اضافه میشن. اونوقت چکار کنیم؟

و البته به نظر من ترتیب اصلا مشخص نیست و امکان جابجایی هست.وابستگی به ترتیب منطقی نیست.

[fzerorubigd]

هدف کلید اینه که یک چیز ثابت باشه از الان برای همیشه،‌البته بعد از اینکه نسخه یک رو ارایه کنیم دیگه تغییرش نمیدیم.
اینه که من دنبال یه روش انسانی بودم. مثلا برای روز اول نوروز
newrouz
یا یه همچین چیزی. بعدش هم کلید کافیه که تو یه تقویم یکتا باشه نه تو سراسر تقویمها.

مزیت روش تو اینه که میشه اعتبار سنجیش کرد و بحثی هم توش نیست.

[neda1985]

چرا این کلید ها مرتب نیستن؟ تو بیشتر فایل ها این چنین هستن پشت سر هم نیست
مثلا تو فروردین صفر و یک و دو هست بعد رویداد بعدی رفته چهار ، دلیل خاصی داره این شکلیه؟

[fzerorubigd]

نه حقیقتش. یه سورس داشتم که مرتب نبود، یه اشتباهی هم از طرف من اتفاق افتاد و سورت اشتباهی شد، اینه که ترتیبش اینجوریه.
ولی باید حل شه.

[neda1985]

پس فکر کنم یه ایشو براش درست کنیم اگه به من اساین کنید من همه و مرتب میکنم

[fzerorubigd]

ممنون، ولی یه سری مشکل هست
۱- اگه بعدا خواستیم وسطش یه چیزی اضافه کنیم چی؟ یا حتی اگه حذف بخوایم بکنیم.
۲- این کلید چه کمکی میکنه؟ مزیتش اینه میشه براش اعتبار سنجی گذاشت، ولی خوانا نیست و بعدا هم مطمئنم برای هر ویرایشی باید کلی ریویو بزنیم که کلیدش درست نیست درستش کن.
۳- وقتی تقویمها جدان اضافه کردن شناسه به کلید واقعا لازمه؟ مثلا ما تقویم جلالی رو کاملا از هجری جدا میکنیم. چرا باید شماره بزنیم قبلش براش؟

من موافق داشتن کلید هستم، ولی کلید ترتیبی و عددی واقعا خوبه اینجا؟ مثلا اینکه بزنیم
nowruz1
بهتر نیست از
0101001

[fzerorubigd]

از طرفی، نکته مهم اینه که کلید یه بار اضافه بشه و دیگه تغییر نکنه. یعنی نمیشه وقت درست کردن پوشه دیست ساختشون. تغییر شناسه رو خودتون قطعا میدونید چه دردسرهایی اضافه میکنه در دراز مدت خصوصا اینکه این قراره رفرنس باشه .

[neda1985]

خوب درسته این مشکلات هست، ولی الان من مثلا میخوام کلید های ماه دی و کامل کنم از کجا بدونم مثلا کلید «۲ » تو هیچ ماه دیگه ای نیست؟ مگه اینکه برم دونه دونه ماه ها رو بگردم ببینم این کلید یونیک هست یا نه، مخصوصا اینکه کلید های ایونت ها رفرنس قراره باشن ، تکرای قطعا نباید باشن

[fzerorubigd]

به طور کلی، سعی کنیم از شماره برای
enum
ها اجتناب کنیم بهتره. کامپیوتر مشکلی با هیچکدوم نداره و هم متن اوکیه براش هم شماره، ولی ما آدما متن رو بهتر میفهمیم و ما قراره این مخزن رو نگهداری کنیم نه کامپیوترها :)))‌

[fzerorubigd]

اگه کسی نظری داره لطفا تا پایان امروز بگه، و اگر هم ممکنه با کمک ری اکشن های گیتهاب روی کامنت نظرتون رو بگید (یا کامنت بدید ، زیاد فرقی نداره )

@persiancal/cal-events-reviewer

[hramezani]

@fzerorubigd واسه طول
partial_key
محدودیتی هست؟
مثلا واسه روز بهره وری و بهینه سازی مصرف
efficiency_and_consumption_optimization_day
مناسب هست؟

[okian]

چون قرار هست خروجی محدود به زبان/فورمت خاصی نباشه به نظرم همون عدد بهتر هست چون تمام زبان‌هایی که من می‌شناسم راهکارهای ساده‌تری برای اعداد دارند و یکپارچه تر میشه.
از طرف دیگه معمولا هم از اعداد برای کلید دیتابیس استفاده می‌کنند٬ در صورتی که کسی بخواهد از این کلید استفاده کنه نیازی به مپ کردن ندارد.
البته هیچکدوم این موارد دلیل قاطعی نیست ولی به نظر درنهایت سروکله زدن با اعداد راحت‌تر میاد. 😁

[fzerorubigd]

@okian نکته اینه که ما دو جنبه رو باید در نظر بگیریم ۱- این رپوزیتوری و فایلهایی که قراره ما مدیریت کنیم ۲- فایل نتیجه که توی پوشه dist میاد

برای اولی اصلا عدد مناسب نیست. برای دومی عدد مناسبترینه. پول ریکوئست رو ببین

[okian]

شاید بد نباشه که کلا کلید رو از اولی حذف کنیم و برای دومی جنیرت بشه٬ ترکیبی از تاریخ و ایندکس رویداد در اون روز.
فقط دو مورد رو باید فورس کنیم:
اول: هیچ رویدادی رو بعد ورود نمیشه حذف کرد که مطمئن نیستم چیز خوبی هست یا نه که البته در صورتی هم که در آینده مشکل ساز شد میشه برای موارد حذفی فلگ در نظر گرفت و مورد جدی نیست.
دوم: ورودی جدید همیشه باید در جایگاه درست یعنی بعد از آخرین رویداد ثبت شده اون روز وارد بشه. خوبی اینکار این هست که اطلاعات همیشه بر مبنای روز سرت شده هست و به بررسی و جلوگیری از ورود اطلاعات تکراری کمک میکنه.

[fzerorubigd]

من موافق حذف کلید نیستم. دلیلی براش نمیبینم. یعنی چی میده که حذفش کنیم؟
در مورد ورود اطلاعات و سورت، مساله فقط روز و ماه نیست. اونایی که سال ندارن اول هستن بعد برمبنای سال سورت میشن. اگه مثلا امروز گفتن اول مهر ۴۲ یه مناسبت اضافه کردیم چی؟ چجوری ترتیب رو درست کنیم؟ من کلا مخالف ساختن کلید برمبنای چیزی هستم که نشه دیدش. ترتیب و ایندکس یکی از همین چیزهاست. باید بشمری، قابل دیدن نیست.

[okian]

من متوجه منظورت نشدم فرض بگیر اطلاعات فعلی اینطور هست

- 
   title: A
   month: 7
   day: 1
   year: 1342 # which is optional, right?
- 
   title: B
   month: 7
   day: 1
- 
   title: C
   month: 7
   day: 5

حالا اگر بخواهیم یک مورد جدید برای روز اول ماه اضافه کنیم میشه:

- 
   title: A
   month: 7
   day: 1
   year: 1342 # which is optional, right?
- 
   title: B
   month: 7
   day: 1
- 
   title: D
   month: 7
   day: 1
- 
   title: C
   month: 7
   day: 5

این خیلی راحت در دیف پول ریکوست قابل دیدن هست. چک کردنش که در جای درست وارد شده در یک نگاه مشخص میشه. کسی که داره چک می‌کنه میدونه:
اول: تاریخ ورودی زیریش باید بزرگتر باشه
دوم: برای اینکه مطمئن بشه ورودی تکراری نیست فقط باید موارد بالایی با تاریخ مشابه رو چک کنه و نیازی نیست کل فایل رو بگرده.
من اصرار نمیکنم ولی به نظرم قابل اجراست. میشه تا قبل از ورژن ۱ اینکارو کرد و اگر مشکلی پیش اومد به همین شیوه دستی یا چیز دیگه برگردیم.

[fzerorubigd]

و همچنان بزرگترین ایراد من به این روش، متکی بودن به یه چیزیه که دیده نمیشه. مثل فاصله تو پایتون.