Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

qe: sync @default(now()) and @updatedAt within a request #3200

Merged
merged 1 commit into from Sep 21, 2022

Conversation

tomhoule
Copy link
Contributor

Alternatives: passing the context through explicitly. I tried, it's a massive refactoring.

There are two points of difficulty here:

  • Using the same PrismaValue::DateTime as the value of now() and @updatedAt for the duration of a request. We achieve that through a task local.
  • The loss of precision due to the From<PrismaValue> impl for QueryValue. This is fixed by adding a QueryValue::DateTime variant that preserves the original precision.

@tomhoule tomhoule added this to the 4.4.0 milestone Sep 19, 2022
There are two points of difficulty here:

- Using the same PrismaValue::DateTime as the value of `now()` and
  `@updatedAt` for the duration of a request. We achieve that through a
  task local.
  Alternatives: passing the context through explicitly. I tried, it's a
  massive refactoring.
- The loss of precision due to the `From<PrismaValue>` impl for
  `QueryValue`. This is fixed by adding a `QueryValue::DateTime` variant
  that preserves the original precision.
@tomhoule tomhoule marked this pull request as ready for review September 20, 2022 14:21
Copy link
Contributor

@pimeys pimeys left a comment

Choose a reason for hiding this comment

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

Did you try if this fixes the findMany optimization with dates?

trace_id,
self.force_transactions,
)
super::with_request_now(async move {
Copy link
Contributor

Choose a reason for hiding this comment

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

I know this is the best way for now, I'm a bit worried though somebody adds a new operation, forgets this and we find it out way too late.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As noted above, it will panic very early and unambiguously. One test with an @default(now()) that uses the new method is coverage enough. We both agree it's not the ideal solution, but I'm not too worried about this specific problem.

/// A timestamp that should be the `NOW()` value for the whole duration of a request. So all
/// `@default(now())` and `@updatedAt` should use it.
///
/// That panics if REQUEST_NOW has not been set with with_request_now().
Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, this is cool actually. Better to panic than write a wrong date in a new operation!

Copy link
Contributor

Choose a reason for hiding this comment

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

The only problem I see is somebody adds a new operation, does not test it with now() or updatedAt and the panic is triggered by a user.

@@ -233,7 +228,7 @@ impl QueryDocumentParser {
}

/// Attempts to parse given query value into a concrete PrismaValue based on given scalar type.
pub fn parse_scalar(
Copy link
Contributor

Choose a reason for hiding this comment

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

🥷

@tomhoule tomhoule merged commit fcf3572 into main Sep 21, 2022
@tomhoule tomhoule deleted the qe/per-request-timestamps branch September 21, 2022 07:32
@tomhoule
Copy link
Contributor Author

tomhoule commented Sep 21, 2022

Did you try if this fixes the findMany optimization with dates?

next PR!

@tomhoule
Copy link
Contributor Author

closes #3200

@zmzlois
Copy link

zmzlois commented Jul 12, 2023

Does @default(now()) @updatedAt work now?

SevInf added a commit that referenced this pull request Jan 16, 2024
We implemented introduced consitent `request_now` value in #3200,
however, we've opted out of thread local value if there is no active
tokio handle. This is problem for WASM build, since it does not have
use an actual tokio runtime.

Replacing handle check with `LocalKey::try_with` allows us to use task
local variable without the runtime, while still preserving fallback for
immediate value if task local is not set.

Fix prisma/team-orm#645
SevInf added a commit that referenced this pull request Jan 16, 2024
We implemented introduced consitent `request_now` value in #3200,
however, we've opted out of thread local value if there is no active
tokio handle. This is problem for WASM build, since it does not have
use an actual tokio runtime.

Replacing handle check with `LocalKey::try_with` allows us to use task
local variable without the runtime, while still preserving fallback for
immediate value if task local is not set.

Fix prisma/team-orm#645
SevInf added a commit that referenced this pull request Jan 17, 2024
* qe-wasm: Fix consistent `now()` value

We implemented introduced consitent `request_now` value in #3200,
however, we've opted out of thread local value if there is no active
tokio handle. This is problem for WASM build, since it does not have
use an actual tokio runtime.

Replacing handle check with `LocalKey::try_with` allows us to use task
local variable without the runtime, while still preserving fallback for
immediate value if task local is not set.

Fix prisma/team-orm#645

* Fix formatting

* Reword comment
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.

None yet

3 participants