Robert Craigie

Looking into this a bit myself with a dataset of 500,000 records with 14 columns On my local machine: - Loading from JSON took just over 1 second - Serialising...

> I actually did something a bit different by chunking up create many into multiple create many calls and then using a async.gather to maximize the io bound time. That...

> Yea, the actual generated queries are different I see, I wonder if it would be feasible for Prisma to be smart enough to create a single query from those...

@tday The flask example app uses the synchronous version of the client so you don't actually need to await the the connect but looking back through it, you are right,...

> Ah, I see. I missed that there is a config to make the client synchronous in schema.prisma Yes that is not very clear, I do plan on changing that...

@tday I've isolated this issue down to using HTTP connection pooling. You can monkeypatch the library to remove the HTTP connection pooling although I do not know much this would...

This is no longer a candidate due to: https://github.com/prisma/prisma-engines/issues/2435 We need to implement #99 before supporting this so that we can raise a runtime error ourselves when an invalid type...

This would've prevented #209

This is a high priority for me as it would've prevented bugs and will increase our confidence with the generated types.

As the internal query engine is asynchronous I do not know how this feature would be properly implemented for the synchronous client. The naive solution is to simply use something...