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
Right now, ash does not allow defining update and destroy actions on resources without a PK:
# require_primary_key? false and update :some_update in resource causes the following compile time erroractions->update->some_update:AshPostgres.DataLayerdoesnotsupportupdateactionsonthisresource.Thisiseitherbecauseofalimitationinthedatalayer,orspecificconfigurationoftheresource.
Some databases, e.g. timescaledb extension, do not allow having a PK on a table. Instead of PK, some timescaledb users utilize a unique index based on time + other columns (e.g. id, device_id, time).
While it's possible to define a generic action to workaround this issue, it would cause us to loose action type semantics and other instruments ash provides for update/destroy actions.
Allow manual destroy and update actions to bypass that check
Use the first identity to destroy/update if present, and change that check
Ensure the first identity is always selected if no primary key exists.
@zachdaniel afaiu the first point implies that ash will allow defining manualupdate & destroy actions even if there is no identity/unique index. I believe it makes sense to bypass the check and not require defining any identities because
a) both destroy and update actions might not be limited to a single row and
b) some resources might have their own way for identifying a specific entry they need to update/destroy that is not known for data layer or ash, but rather enforced on a higher level (app, device, transport protocol, etc.). I can imagine a scenario where someone would like to have no unique indices to improve data ingestion performance on some table. They might or might not enforce uniqueness in business logic instead, but regardless of their decision, it makes sense to allow defining manual destroy / update actions in Ash.Resources without any identity.
Short example with comments that might be useful:
attributesdo# not a PKattribute:id,:integerdogenerated?falseprimary_key?falsepublic?trueend# in timescale, tables have to have some timstamp for chunking/partitioning attribute:time,AshPostgres.TimestamptzUsecdoallow_nil?falsepublic?trueconstraintsprecision: :microsecond,timezone: :utcendendrelationshipsdobelongs_to:device,Devicedoallow_nil?falsepublic?trueendendresourcedorequire_primary_key?falseendidentitiesdo# in our use case we tolerate having this unique index, but at some point for specific hypertables,# we might consider dropping this index whatsoever for ingestion performanceidentity:unique_id_device_id_time,[:id,:device_id,:time]endactionsdodefaults[:read]destroy:expunge_olddo# ... destroy multiple entriesenddestroy:delete_specificdo# ... destroy specific resource, based on# identity or with manual actions based on our own logic unknown to ash & data layerendupdate:reset_timedo# ... same but for updateendcreate:createdo# create works fineaccept:*# allow upsertsupsert?true# use ON CONFLICT (:id, :device_id, time)upsert_identity:unique_id_device_id_time# force DO NOTHINGupsert_fields[]endend
The text was updated successfully, but these errors were encountered:
timadevelop
changed the title
Support destroy and update actions on resources that have at least one identity even if there's no primary key
Support destroy and update actions on resources that have no primary key
Dec 13, 2024
Right now, ash does not allow defining
update
anddestroy
actions on resources without a PK:Some databases, e.g. timescaledb extension, do not allow having a PK on a table. Instead of PK, some timescaledb users utilize a unique index based on
time
+ other columns (e.g.id, device_id, time
).While it's possible to define a generic action to workaround this issue, it would cause us to loose action type semantics and other instruments ash provides for
update
/destroy
actions.As @zachdaniel noted before https://discord.com/channels/711271361523351632/711271361523351636/1317093457982001225, perhaps it makes sense to
@zachdaniel afaiu the first point implies that ash will allow defining manual
update
&destroy
actions even if there is no identity/unique index. I believe it makes sense to bypass the check and not require defining anyidentities
becausea) both destroy and update actions might not be limited to a single row and
b) some resources might have their own way for identifying a specific entry they need to update/destroy that is not known for data layer or ash, but rather enforced on a higher level (app, device, transport protocol, etc.). I can imagine a scenario where someone would like to have no unique indices to improve data ingestion performance on some table. They might or might not enforce uniqueness in business logic instead, but regardless of their decision, it makes sense to allow defining manual
destroy
/update
actions in Ash.Resources without any identity.Short example with comments that might be useful:
The text was updated successfully, but these errors were encountered: