package dev.privacyllc.period.core.data

/**
 * What a write to the period history did.
 *
 * ## Why this exists rather than an exception
 *
 * `period_records.startDate` is UNIQUE, and inserts ABORT rather than REPLACE —
 * both deliberate, so a duplicate cannot silently destroy the original row.
 * The consequence was a defect found on a device: tapping **Started today**
 * twice threw `SQLiteConstraintException` out of `viewModelScope.launch`, which
 * has no handler, and the app died on the most ordinary interaction it has.
 *
 * The mistake was treating "already recorded" as an error. It is not one — it
 * is a completely reasonable thing for a person to do, twice, when they are not
 * sure the first tap registered. The database constraint is right; the API
 * around it was wrong to make an exception the only way to say so.
 *
 * So the ordinary outcomes are values. A genuine fault — a full disk, a corrupt
 * database — still throws, because that is not something a caller can sensibly
 * carry on from.
 */
sealed interface PeriodWriteResult {

    /** A new record was written. */
    data class Added(val id: Long) : PeriodWriteResult

    /** That date was already recorded. Nothing changed, and nothing is wrong. */
    data class AlreadyRecorded(val id: Long) : PeriodWriteResult

    /** An existing record was changed. */
    data object Updated : PeriodWriteResult

    /**
     * The edit would have collided with a different record on that date.
     *
     * Refused rather than merged: two records on one day is a data question
     * only the user can answer, and picking for them would delete a period they
     * entered.
     */
    data class Conflict(val existingId: Long) : PeriodWriteResult

    /** The record was gone by the time the write ran. */
    data object NotFound : PeriodWriteResult
}
