Re:Ruby 3.3
by ochoseis on Monday December 25, 2023 @02:41PM
(#38765468)
Further, with a lot of the batteries-included web frameworks you end up with a ton of suboptimal database queries (e.g. unintentional query-in-loop). Some would argue that you can just profile your code and optimize the hot spots, but I would tend to think it still slows you down quite a bit overall.
[ Parent
| on HN ]
Re:Ruby 3.3
by seabrookmx on Monday December 25, 2023 @02:58PM
(#38765583)
So common that apps like sentry have special logic to detect these "N+1" queries. We find DRF is awful for this.
Re:Ruby 3.3
by neonsunset on Monday December 25, 2023 @05:41PM
(#38766953)
One of the biggest breaking changes that EF Core did was to explicitly disallow such generated queries that required application-side evaluation and could not get compiled to pure SQL (you can get other behavior back with a toggle but it is discouraged).
I strongly believe it is wrong to do otherwise and is a source of numerous footguns unless you invest in tracking them down.
Re:Ruby 3.3
by seabrookmx on Monday December 25, 2023 @07:18PM
(#38767684)
I will admit I'm behind the state of the art with EF, but I switched to dapper in the early days of dotnet core and never looked back. It gets out of my way so I can properly utilize postgres' advanced features like jsonb while cutting out a lot of the boilerplate associated with hand-rolled queries.
Re:Ruby 3.3
by neonsunset on Tuesday December 26, 2023 @05:09AM
(#38770385)
Dapper is great. I'm very happy that there now exists an AOT-supporting flavour of it too: https://aot.dapperlib.dev/
As for EF Core - it very good as of today (has it ever been bad?). You can transparently compose your queries with `context.FromSql(...).SingleAsync()` which will use string interpolation API to consume your plain $"SELECT * FROM {myTable} ..." and make it injection-safe and transform passed arguments as appropriate. It's quite handy.