Skip to content

Conversation

@G8XSU
Copy link
Contributor

@G8XSU G8XSU commented Jul 25, 2024

We use application level timestamps to maintain
dialect compatibility between different SQL variations. We truncate timestamp to granularity of days for privacy reasons.

@jkczyz
Copy link
Contributor

jkczyz commented Jul 29, 2024

Change looks good, but I have a couple questions:

  • By "dialect compatibility" do you mean implementations use say seconds vs milliseconds, so we need to normalize on something with common granularity?
  • What are the new columns used for?

@G8XSU
Copy link
Contributor Author

G8XSU commented Jul 29, 2024

"dialect compatibility"

There are other ways to achieve created_at and updated_at timestamps with only using SQL query or using DB procedures etc. But we do this at application level, to keep sql query simple(having this truncate logic and procedures in sql is complex) and for dialect compatibility, which means this same query will more or less work b/w postgres/mysql/sqlite etc. whereas for other methods we might have to rely on exact db sql syntax.

What are the new columns used for?

They aren't used for any specific rn, mainly useful for audit purpose. Could be used by hosting providers to "expire data" if lets say a user hasn't paid in last 2 years.
It might also be useful if spiral wants to host a test-vss-instance for developers to try out, but doesn't want to store data forever. (for e.g. we can delete data older than ~2 weeks.)

We use application level timestamps to maintain
dialect compatibility between different SQL variations.
We truncate timestamp to granularity of days for privacy
reasons.
This is to reflect changes from lightningdevkit#25 in tests.
@G8XSU G8XSU merged commit b6ca47d into lightningdevkit:main Jul 29, 2024
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.

2 participants