asobi_quest_progress (asobi_quests v0.2.2)

One player's counter for one quest in one period.

This row is the counter. asobi has no counter primitive, so quests brings its own: counter is incremented in the database with a single UPDATE ... SET counter = counter + $1, which is why two concurrent kills from two match processes cannot lose an increment.

target is copied from the quest at row creation rather than read through the association. Retuning a live quest from 10 to 20 must not un-complete the players who already finished it, and a completed row that reverts to incomplete after a claim is a duplicate reward.

period_key is what makes a daily quest a daily quest: the same player and quest get a fresh row per window (see asobi_quests_period). A non-recurring quest uses the constant all, so the unique index covers both cases with no nullable column.

Summary

Functions

associations()

The two foreign keys, both cascading.

fields()

generate_id()

indexes()

table()

Functions

associations()

-spec associations() ->
                      [#kura_assoc{name :: atom(),
                                   type :: belongs_to | has_one | has_many | many_to_many,
                                   schema :: module(),
                                   foreign_key :: atom() | undefined,
                                   ref ::
                                       #kura_ref{fields :: [atom()] | undefined,
                                                 target :: module() | undefined,
                                                 target_key :: [atom()] | undefined} |
                                       undefined,
                                   join_through :: binary() | module() | undefined,
                                   join_keys :: {atom() | [atom()], atom() | [atom()]} | undefined,
                                   through :: [atom()] | undefined,
                                   on_delete :: kura_schema:on_delete() | undefined}].

The two foreign keys, both cascading.

player_id must cascade. asobi's guest reaper deletes players, and with no_action the first progress row makes that player undeletable - the reaper swallows the constraint violation as skipped, so the visible symptom is guests quietly ceasing to be reaped rather than an error anyone sees.

quest_id cascades for the same class of reason: progress against a deleted definition is unreadable, and keeping it would block the delete.

fields()

-spec fields() ->
                [#kura_field{name :: atom(),
                             type :: kura_types:kura_type(),
                             column :: binary() | undefined,
                             default :: term(),
                             primary_key :: boolean(),
                             nullable :: boolean(),
                             virtual :: boolean()}].

generate_id()

-spec generate_id() -> binary().

indexes()

-spec indexes() -> [{[atom()], map()}].

table()

-spec table() -> binary().