Handling Recurring Entries

[needim]

In gider.im, recurring entries are efficiently managed with a smart data approach. The database schema, which involves several key tables (EntryTable, RecurringConfigTable, and ExclusionTable), ensures flexibility and precision in handling different types of recurring entries. This is how the system works:

---

1. EntryTable

This table represents the core of each entry, whether it's an income or expense.

• date: The date the entry occurred or is planned to occur.
• type: Defines whether the entry is an "income" or "expense."
• recurringId: Links the entry to a RecurringConfig record if it's part of a recurring series.
• fulfilled: A boolean flag to indicate if the entry has been processed.
• groupId and tagId: Optional fields to categorize and tag entries.

---

2. RecurringConfigTable

The RecurringConfigTable defines the recurring behavior for an entry. Each recurring entry is tied to a configuration that determines its frequency.

• frequency: Specifies how often the entry repeats (weekly, monthly, or yearly).
• interval: Defines the interval between recurrences (e.g., every 2 months).
• startDate and endDate: Marks the period during which the recurrence is active.
• every: Defines how many times the recurrence should happen based on the interval.

If endDate is null, it means infinite recurring.

---

3. ExclusionTable

This table manages any exceptions to the recurring pattern.

• recurringId: Links to the recurring entry that has exclusions.
• date: Specifies the date that should be excluded or modified.
• reason: Indicates whether the entry is excluded due to deletion or modification.
• modifiedEntryId: If a recurring entry is modified, this field points to the new modified entry.

---

Handling Recurring Entries in Different Scenarios

1. Regular Recurring Entries:
   If an entry has a recurring configuration, new entries will be automatically generated based on the RecurringConfig. Since we are allowing infinite recurring entries, we are limiting this generation for max 24 months.

2. Exclusions:
   When a recurring entry needs to be skipped or modified on a particular date, the ExclusionTable handles this by either marking the entry as deleted or pointing to a modified version of the entry. This ensures that recurring entries remain flexible and adaptable to real-world changes.

3. Modifications:
   If an entry in a recurring series is edited (for example, a change in the amount or date), a new entry is created, and an exclusion is added to avoid the original entry's creation. This preserves the history of the recurring pattern while allowing changes for future instances.

---

Future Plans

In the future, I plan to write more tests to ensure that these cases are handled safely and accurately during development, without the fear of breaking existing functionality.

---

This approach ensures that gider.im can flexibly manage complex recurring patterns while maintaining a clean, manageable database structure. Feedback and contributions are always welcome!