createQueryId
Is this function supposed to be exported and used in users code? I'm handling query execution with a custom executor and the
executeQuery method asks me for a QueryId. Am I supposed to use kysely internal implementation or am I free to use a custom one? It's just a random string I see, but does it involve something else internally?
I'm asking cause the default import is set to: import { createQueryId } from "kysely/dist/cjs/util/query-id"13 Replies
Having a custom executor is not something I thought people could do and it's not officially supported. That's the reason why
createQueryId is not public.
I didn't think people would ever need to create their own query idsOk so that’s not thought of being public. It’s ok, it was just to double check I was doing everything fine (or wrong 😅)
My use case, if that could help, is using kysely with https://github.com/Effect-TS/effect effect system. So I need to separate query building from query execution, to better compose functions (effects)
GitHub
GitHub - Effect-TS/effect: A Fully-fledged functional effect system...
A Fully-fledged functional effect system for typescript with a rich standard library - GitHub - Effect-TS/effect: A Fully-fledged functional effect system for typescript with a rich standard library
Basically I’m separating the kysely instance from the kysely query executor you get from retrieving
getExecutor and then I use the first for build Compilable queries and I use the separated query executor to execute those. So I need a queryId
Are there some technical reasons to choose a specific implementation for the createQueryId or I can just use whatever random string I want?Thanks! I'm doing something similar, just wanted to be sure I could use whatever
queryId I wanted as long as it's unique (I guess) as when using UUIDs
On top of such recipe, there's no way to "omit" the execution bit from the query builder right? So for example if I'm mistaken and use the dummy kysely instance to do an execute and not just compile I get a runtime error without prior warning, right?On top of such recipe, there's no way to "omit" the execution bit from the query builder right? So for example if I'm mistaken and use the dummy kysely instance to do an execute and not just compile I get a runtime error without prior warning, right?According to the recipe:
Trying to execute queries using "cold" kysely instances will return empty results without communicating with a database.
Yes, but that doesn't prevent me or someone else from using kysely to generate promises which will never get correctly executed at runtime, while being correct at compile-time.
My use case is the one where I create a kysely instance, get the executor from it and wrap it with a function "execute" so that it run the promise with a
Compilable, catch the result and return a Result | Error basically, so that it never "crash/throw".
I then proceed to use the kysely instance as a query builder. It would be nice to evict all the "execution" capabilities from it in order to make it typed as it was only a query builder.
so that I'm forced to use my execute function which has the kysely executor inside, everytime I need to execute something created by the kysely query builderKysely is dialect agnostic by design. The best we could do is introduce a breaking change that throws an exception when exeucting with a cold instance.
This is such a niche use case, that I'm not 100% is worth it
I was asking if it was feasible at all to completely separate the query building capabilities from the exection features. I guess that's dialect agnostic too (it would be more, nonetheless)
maybe dummy driver could have options.. like
throwOnExecuteIt's a type thing at the end, removing
.execute methods from query builders
I assume it's not so easy now with a lot of types 😄its 100% not worth the complexity it brings