ساختارکلی

[Ali-Yazdani]

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

[fzerorubigd]

اوایل خودمم این نظر رو داشتم، ولی مساله اینه که رویدادهایی مثل نوروز که چند روزه باشن درصد خیلی کمی دارن. یه مساله هم هست اونم چگونگی کوئری نهاییه.

با توجه به استفاده‌ای که من براش دارم، من معمولا میخوام که رویدادهای مرتبط با یه روز خاص رو نشون بدم. یعنی مثلا رویدادهای روز دوم فروردین. اینجوری که الان هست یه فیلتر با یک شرط کافیه، - فرض کن اینا رو ملت میذارن تو دیتابیس - ولی اگه یه رویداد برای چهار روز داشته باشیم، کوئری پیچیده تر میشه. حجم دیتا اینجا مساله نیست، نهایتا فکر نمیکنم این از چند مگابایت فراتر بره، ولی راحتی دسترسی به نظر من مهمه.
همچنین میتونی #2 رو ببینی که هنوز اضافه نشده.

[Ali-Yazdani]

خوب پس دو دید مطرحه:

1. قائم به رویداد بودن
2. قائم به روز بودن

برای حالت دوم هم من پیشنهادم ساختار بلاک کلی هست چرا که با همه ی رویدادهای یه روز رو میتونیم توی یه بلاک مشخص کنیم وما روز هایی که چند مناسبت در اون روز باشه زیاد داریم از طرفی میتونیم از ترکیب روزو ماه و ... برای درست کردن یه partial-key واحد استفاده کنیم.

[fzerorubigd]

partial_key توی اسمش عبارت partial رو داره به یه دلیل، اونم اینکه این کلید نیست، یه بخش از کلیده. کلید اصلی تو خودش روز، و ماه رو داره
https://github.com/persiancal/cal-events/blob/master/cmd/thetool/common.go#L39
کلید اصلی یه جای دیگه درست میشه (کد بالا) و درنهایت کلید جزیی تو خروجی حذف میشه. این کلید جزیی هدف نیست، صرفا یه ابزاره که مطمئن شیم کلیدهای خروجی تکراری نیستن.

از طرفی، فعلا بحث تفکیک به رویداد هم مطرحه یا حتی به روز. اینجا رو ببین #90 البته اونجا فقط رویداد مطرحه ولی من با شکستن به یه فایل برای یه روز هم فکر کردم که نیازه اونجا درموردش صحبت و بحث شه.
در هر صورت، ساختار تغییر چندانی نمیخواد، چون یک روز میتونه یک آرایه از رویداد داشته باشه و درنهایت همینه حالا اینکه رویدادها رو چجوری جاگیر کنیم تو یه فایل، فکر نمیکنم خیلی بحث برانگیز باشه.