You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The field adopted_probe in gp_credits_additions is marked as a foreign key with on delete set null. On the probes page, we're using an is not null check to determine if the addition of credits was related to a probe or something else (sponsorship, etc.). This, unfortunately, means that when a probe is deleted, all its credits additions become "not related to a probe," and the credits total on the probes page doesn't match the credits total on the credits page, which is confusing.
My first thought was simply dropping the foreign key, but there are related issues with how we currently handle additions:
there's no "type" to programmatically distinguish the cause of addition
the meta comment is a bit problematic as it's unstructured text, and if we want to update the wording, it requires regex based updates of the whole table
Here's an idea that might solve all of the above:
drop the comment and adopted_probe fields
add a reason enum, which can be adopted_probe, recurring_sponsorship, one_time_sponsorship
add a meta field as json, which contains whatever references we need based on the reason; e.g. for probes it would contain the name and IP, and the client would construct the comment based on that
The field
adopted_probe
ingp_credits_additions
is marked as a foreign key withon delete set null
. On the probes page, we're using anis not null
check to determine if the addition of credits was related to a probe or something else (sponsorship, etc.). This, unfortunately, means that when a probe is deleted, all its credits additions become "not related to a probe," and the credits total on the probes page doesn't match the credits total on the credits page, which is confusing.My first thought was simply dropping the foreign key, but there are related issues with how we currently handle additions:
comment
is a bit problematic as it's unstructured text, and if we want to update the wording, it requires regex based updates of the whole tableHere's an idea that might solve all of the above:
comment
andadopted_probe
fieldsreason
enum, which can beadopted_probe
,recurring_sponsorship
,one_time_sponsorship
meta
field as json, which contains whatever references we need based on thereason
; e.g. for probes it would contain the name and IP, and the client would construct thecomment
based on thatPartly related #22.
The text was updated successfully, but these errors were encountered: