larshei
I have created a Resource that I wanted to store with CubDB as the datalayer.
However, I run into the following error message:
AshCubDB.DataLayerdoes not supportupdateactions on this resource.
If I remove the update: :* from the resource’s default action, I get the following error instead:
AshCubDB.DataLayerdoes not supportcreateactions on this resource.
Resource
I created a simple key-value store as an example Resource
defmodule MyApp.Kve do
use Ash.Resource,
domain: MyApp,
data_layer: AshCubDB.DataLayer
attributes do
attribute :key, :string
attribute :value, :string
end
actions do
defaults [:read, :destroy, create: :*, update: :*]
end
cubdb do
directory "/data/cubdb/kv.cubdb"
auto_compact? true
auto_file_sync? true
name :kv_storage
end
end
Turning key into a primary_key does not change anything.
Versions
From mix.lock
"ash_cubdb": {:hex, :ash_cubdb, "0.6.2", "828203fcc1a48cf5538a7d5ef0dfa353725859da90619dee8360975785adc6f2", ...
"ash": {:hex, :ash, "3.2.4", "81842a319aa18e974c9e87905c2a30b42e5084f10bf2931a6709e26398eeb5a6", ...
Where Next?
Trending in Discussions
Other Trending Topics
Latest Ash Threads
Chat & Discussions>Discussions
Latest on Elixir Forum
Sponsor Spotlight
Build Elixir applications with speed and confidence.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #graphql
- #ai
- #genstage
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
First 5 of 5 Posts
zachdaniel
@jimsynz would be able to say more, as this is his package, but it looks like the
can?function for the data layer checks the writability of the target directory:Ash checks
can?/2at compile time (which it didn’t always do, so that is likely whyash_cubdbdoes this).I’ve made a branch on my own fork with this fixed:
{:ash_cubdb, github: "zachdaniel/ash_cub_db", branch: "dont-check-dir"}You could use this temporarily and then open an issue on the repo for
ash_cubdb.larshei
I see, the directory did not exist yet, so the checks probably failed. Did not expect this during compile time, as with mounted volumes etc the folders probably dont even exist in most build contexts.
Thanks!
zachdaniel
Yeah, it doesn’t make sense to happen at compile time, but at some point in the past that
can?wasn’t called at compile time. Thecan?/2shouldn’t use context related things (like file existence or environment variables).jimsynz
Oh dear. I didn’t realise that
can?/2is now being called at compile time. I guess they should all just return true then.zachdaniel
Not your fault, it was changed in core at some point, and I didn’t anticipate the other kind of usage.