AshCubDB.DataLayer does not support actions

Ash Forum Ash Chat
,
1

I have created a Resource that I wanted to store with CubDB as the datalayer.

However, I run into the following error message:

AshCubDB.DataLayer does not support update actions on this resource.

If I remove the update: :* from the resource’s default action, I get the following error instead:

AshCubDB.DataLayer does not support create actions 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", ...
2

@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:

  def can?(resource, :create), do: Dir.writable?(resource)
  def can?(resource, :update), do: Dir.writable?(resource)
  def can?(resource, :upsert), do: Dir.writable?(resource)
  def can?(resource, :destroy), do: Dir.writable?(resource)
  def can?(resource, :read), do: Dir.readable?(resource)

Ash checks can?/2 at compile time (which it didn’t always do, so that is likely why ash_cubdb does 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.

1 Like
3

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!

4

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. The can?/2 shouldn’t use context related things (like file existence or environment variables).

5

Oh dear. I didn’t realise that can?/2 is now being called at compile time. I guess they should all just return true then.

6

Not your fault, it was changed in core at some point, and I didn’t anticipate the other kind of usage.