Dropping created_at in favor of UUIDv7? (Ash-3.1)

Ash Forum Ash Questions / Help
, ,
1

Hi all

I have started a brand new project. Usually, I would have created a pair of timestamp attributes created_at and updated_at.

Now with the UUIDv7 type, I’m seriously considering dropping created_at altogether.

Comments on pros and cons?

PS. I do want to display record creation date in some places.

Best regards

2

I guess you could create a stored procedure for

SELECT to_timestamp(x'0187296000797352b8a70b7088b46d0f'::bit(48)::bigint / 1000)

See postgresql - How to extract timestamp from UUID v7? - Stack Overflow

I’m sure there’s an Elixir function you could call to do the same.

Are you trying to save disk space? An extra “thing to do?” Personally I would not do this.

3

Ash 3.1 already includes a postgresql function to do that timestamp_from_uuid_v7

Yeah, it’s getting inconvenient dropping created_at altogether.

4

I feel like it’s good enough to replace created_at if you will only need the timestamp as a default sort or for forensic/recovery usage. If you will be using and regularly displaying the timestamp, I’d probably keep the timestamps columns both for simplicity and performance.

1 Like
5

I would very much advise against using the timestamp from the uuidv7 for anything at all except for:

  • something that necessitates saving every byte, like high volume time series data

  • you absolutely need to have a well-ordered set of records by when they were created.

It is important to note that “well-ordered” does not mean “objectively true”. For example, two records can be created at the same millisecond, but the system unambiguously sees one as being either before or after the other because everything after the timestamp part sorts unambiguously.

AshDoubleEntry uses a similar thing (ULID, but it will be updated to use uuidv7 in the future), to ensure that there is always one-true-ordering of transfers in a system.

Aside from those cases, add a created_at timestamp :slight_smile:

6

If you use UUIDv7 for timestamps, than consider moving a data from one table to another. You’ll also have to copy a UUID from the past into new place in the table (otherwise you’ll lose inserted_at logic), which break this clustered index feature of the UUIDv7.

I’d keep two columns

1 Like