Skip to content

add a created_at field to the schema - #60

Merged
pyoxa merged 7 commits into
mainfrom
add-timestamps-schema
Nov 4, 2025
Merged

add a created_at field to the schema#60
pyoxa merged 7 commits into
mainfrom
add-timestamps-schema

Conversation

@pyoxa

@pyoxa pyoxa commented Oct 29, 2025

Copy link
Copy Markdown
Contributor

Adds a CreatedAt field to the proto and database schema.
To work with using the generated proto type as the database model, custom serializers are used

For database/local providers (both upgrades and versions), the field is obvious.
For the chain upgrade provider, the SubmitTime is used as the created at field for upgrades.

Closes #12

@pyoxa
pyoxa force-pushed the add-timestamps-schema branch from 5e7b01d to 6e3838b Compare October 29, 2025 15:14
@pyoxa
pyoxa requested review from DavidVentura and qezz October 29, 2025 15:15
@mkaczanowski

Copy link
Copy Markdown
Contributor

as for me lgtm (apart the linter notice about unused field)

@pyoxa

pyoxa commented Oct 30, 2025

Copy link
Copy Markdown
Contributor Author

i'll follow up with a pr for UI changes

@pyoxa
pyoxa force-pushed the add-timestamps-schema branch from 6ce13b1 to 04e3089 Compare November 3, 2025 19:34
t = v
case string:
var err error
t, err = time.Parse("2006-01-02 15:04:05.999999-07:00", v)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this timestamp is slightly different to

	RFC3339Nano = "2006-01-02T15:04:05.999999999Z07:00"

is that intentional? (T -> , Z -> -, 999999999 -> 999999)

does it make sense to store the timestamp as a string, vs a timestamp (numeric 64b value)?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is that intentional? (T -> , Z -> -, 999999999 -> 999999)

afaict this is the protobuf's timestamp format, although i might be wrong on this one as im not super familiar with protobuf

does it make sense to store the timestamp as a string, vs a timestamp (numeric 64b value)?

wdym?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i meant that instead of having a date type we could store an uint64 but it's 0/5 for me

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you dont mean storage, but the protobuf schema? because in postgres we store timestamps

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah wtf github trolling me

@pyoxa
pyoxa merged commit 77910d7 into main Nov 4, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

keep timestamps for upgrades and versions entries

3 participants