Are default timestamps not allowed to be null in the database layer?

Chat & Discussions Chat / Discussions
,
1

I realized that Ash generates timestamps in the application, which is what I want. To be sure, I removed the default values for those fields in the database migration. However, now when I run mix ash_postgres.generate_migrations, it wants to add a default value back in the snapshot files.

How can I prevent this?

image
image455×454 35.7 KB

  attributes do
    attribute :id, :uuid do
      primary_key? true
      allow_nil? false
      default &UUIDv7.generate/0
    end

    attribute :title, :string do
      allow_nil? false
    end

    attribute :content, :string do
      allow_nil? false
    end

    create_timestamp :inserted_at
    update_timestamp :updated_at
  end

Is there a way to prevent that globally?

Thank for this amazing framework :grinning_face:

Im using: ash 3.5.33, ash_postgres: 2.6.14, phoenix:1.7.21

2

Looking at the docs, you should be able to set the default of the timestamp attributes to nil. :thinking:
To have it global you would need to make your own dsl and use that. Or just use attribute.

3

Sorry, I meant leaving it with a default of nil at the database level, but defining the default in Ash instead. That way, mix ash_postgres.generate_migrations won’t keep generating changes in resources_snapshots for it. :+1:

4

If I’m not mistaken, I think the default is the fragment added. :thinking:

5

Is there a particular reason you don’t want the database default? You can have both just fine in general, application-side defaults and database defaults.

6

Now that I think about it, it’s just a habit. I’m used to lowering the database’s CPU usage, and I liked making sure Elixir was the one generating the default values. But now that you mention it, I could check the SQL logs for that. :+1:

7

Yeah ultimately it should be safe to have it in both places, and acts as a benefit for retaining application behavior even when data is inserted directly into the database.