-
-
Notifications
You must be signed in to change notification settings - Fork 579
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
Move more input planning to runtime #2376
base: runtime-orderby
Are you sure you want to change the base?
Conversation
…me ordering on SQL
|
Description
Yet more related to
This introduces the new
applyInput
andbakedInput
steps to replaceapplyPlan
andinputPlan
needs at runtime; and then uses them to move the following from plantime to runtime:orderBy
to runtime #2357 mostly, but also backing out some of those changes)only
argument)It also gets rid of
ModifierStep
and replaces it withModifier
(which runs at runtime, as part of the newapplyInput
) and implements necessary APIs to make transition a little softer (e.g.$foo.placeholder(value.getRaw(), codec)
is no longer available at runtime, so instead you dosqlValueWithCodec(value, codec)
).FieldArgs is now only used for the field itself, and a new FieldArg type is used for argument applyPlan; no other inputs support applyPlan or inputPlan any more. There's no need for the autoApplyAfter... fields any more either.
Performance impact
Unknown, not really thinking about performance right now. Probably some trade-offs, but also the SQL that's generated can be more efficient so even if it's slower in Node it should be faster in Postgres.
Security impact
Less load on the DB (hopefully) and less ability to have drastically long planning time in Grafast - win.
Checklist
yarn lint:fix
passes.yarn test
passes.RELEASE_NOTES.md
file (if one exists).