[HELP]: I'm trying to re-create a CTE-insert in drizzle, having some difficulties
How does the query above translate to drizzle?
I think more examples that translates to the above would be awesome in the docs, I've been fighting a bit with the API. I know from the start how to do it on sql, but sometimes it gets really hard translating to drizzle.
I feel this could be solved with more examples, maybe?
37 Replies
We spoke about that few days ago here:https://discord.com/channels/1043890932593987624/1145679831841919006 (scroll to the end)
Hope it helps
Well, looking at that thread it doesn't show much. I'm also just using
sql
template directive with the CTE
Maybe there could be a solution using the core api
Also a very, very wierd behavior
I can't get inference from the sql<OrderProduct>
It infers data as unknown
the execute
method should pick up the type from the sql<T>
Do you have anything in mind why this would happen?
Am I doing something wrong? š®I can reproduce. Not sure if it is expected š§
š¢
@Andrew Sherman Is this a bug?
It seems this query could be written like this:
I'm assuming a lot of table a column names here. So you might need to edit it
btw, you might want to do this in a transaction
I thought the same but not sure if running them separately (not in the same execute) will produce the same result
db.$with
, only sets up the with for drizzle, it doesn't send anything to the DB.
I forgot to await the db call. Will editYou're doing two queries here
Isn't real 1-1 to the query I stated above
I think this might be a limitation of drizzle?
I mean, if I understood correctly.
Then I don't think I understood your query. Can you write it in plain SQL? cause I believe you might have just put the what you would put in the sql operator
The values from the insert are coming from the select?
Yep!
Oh, my bad
The select is just to format the data so that the input can accept it
I do it all the time
But sometimes this tricks get super hard to implement in drizzle xD
Sql is just boom, done. There's lot of mental effort to get this right
Maybe I just lack examples
I think this might work, I just don't have anywhere to test it right now
The types might complain though
Oh okay
So basically you passed the CTE to below the insert
Yeah I didn't thought that way
Yeah that might work
Smart
Thanks!
Still I wonder if sometimes isn't just easier to write sql
Like
vs
Well, you can always write SQL, but you always end up writing just text, no intelisense or type safety
That query should have correct types
BTW, I'm hoping that query works, I'm not 100% it does
Yeah the intelisense & typesafety is what is making me stay, but still that API takes a lot of mental effort to adopt š¢ . There's a bit of a learning curve, even if you're actually cool on the sql
I think it needs to improve a little, rn it's a bit confusing. At least for me.
Thanks so much for the effort @angelelz
Will check it out
I honestly think it's quite the opposite. What I've seen is people without SQL experience struggle with the crud API from Drizzle. You can see how you can translate from SQL to Drizzle syntax directly. There are changes we have to do to translate it to JS/TS like the eq operator has to be a function and it's written before the 2 operands, but there is no other way to express that in JS.
I this example you can see how the
db.$with
just saves the cte query in a Drizzle data structure for use in the actual select, very similar to how you would do it in SQLYeah but it's a lot more verbose
But I get your point š
Not hating on the tool, just that sometimes I know exactly what I want in sql, but translating to drizzle is a little hard
One example
To achieve this in drizzle it's not obvious
I need to
It's very wierd
Or is there another way of doing it?
Uf
If you do it like that, the type is going to be wrong
I suggest you do the subqueries as separate variables
More readable
The type is not going to be wrong
I won't retrieve col_1 or col_2
They are just for ordering and other specific use cases
Maybe I should have mentioned that
And the subquery here is not an option...
I'm just creating columns here, I can decide If I want retrieve that data to the select or not
It would be cool for the from accepted an array, that way I could create as much columns as I wanted, like this:
This would make a lottttt of sense
And would make it possible for me
These are just my takes for the first time using the library.
At the beginning looked awesome, but now there's a bit of an effort...
Maybe I'm doing it wrong XD
The "Maybe I'm doing it wrong" is usually a sign the the library we're using is missing some features
Drizzle is not yet 1 to 1 fully compatible with SQL
It's not v1 yet
That's why we have the sql operator for all the stuff that we're missing
True š. Well, maybe my rant here may have brought ideas
Got it!
Can you open an issue in github for the feature you're referring to?
Sure, I'll do it
šŖ
Now, let me ask you a question
Is the query you're trying to build possible with joins?
Uh yeah I could just join and select inside the join, acting like a table
That's smart
Hmmmm
Our join api is pretty good, type safe
And you can also use the relations API
It's not possible, drizzle only has available 3 types of joins
Wait
I could do that with UNION
Not join
Because some columns I just need to calculate shit on the side
Lol, we don't suppor unions yet
E.g ranking etc
Then I would filter the rows based on the results of those columns
I think I could use joins after all, if those columns had some ID that where I could do
(on(table.id, col_from_specific_select.id))
I have an open draft PR to add union to drizzle
Nice man!
Looking good
I'll keep digging, I'll try to come-up with some different solutions
You may have given some ideas that made me think of different solutions
Much thanks
I believe joining tables is faster than selecting from several selects
I might be wrong
Now I want to do some explain analize lol
I don't think so, the join still needs to compare every result and align with the ID of different tables (or subqueries acting as a table)
Not sure tho
ahahahahah
Great question