71–80 of 220 posts
I hate ORMs with the fury of a thousand suns. The problem is that I know SQL but now I have to spend a bunch of time trying to figure out how to convert SQL into ORM X just so it can convert it back to inefficient SQL. SQL mostly translates between various databases but ORMs are unique and you have to learn a new API for each one. I'm on a project using TypeORM and it has been fantastic at helping developers on my te…
During my years as a dev i have really started to dislike ORMs. They always fail in the end. SQL is universal, and transfers between languages and tech fields. This is why im pro-sql, and always try to avoid unnecessary abstractions. I have actually went back to writing pure SQL in files, and using those as params for whatever db engine i use, this makes it even possible to reuse the code in other projects (even its…
So really, just like most other programming decisions, the answer is "it depends".
During my years as a dev i have really started to dislike ORMs. They always fail in the end. SQL is universal, and transfers between languages and tech fields. This is why im pro-sql, and always try to avoid unnecessary abstractions. I have actually went back to writing pure SQL in files, and using those as params for whatever db engine i use, this makes it even possible to reuse the code in other projects (even its…
I hate ORMs with the fury of a thousand suns. The problem is that I know SQL but now I have to spend a bunch of time trying to figure out how to convert SQL into ORM X just so it can convert it back to inefficient SQL. SQL mostly translates between various databases but ORMs are unique and you have to learn a new API for each one. I'm on a project using TypeORM and it has been fantastic at helping developers on my te…
Where I'm at now, we have a big huge Java app that uses MyBatis ( https://mybatis.org/mybatis-3/ ) It involves writing SQL inside of XML files and doing a lot of manual mapping from columns back to the objects. At first I REALLY disliked it but over time I have grown to absolutely love being able to just write SQL queries that can return whatever. Writing raw SQL really lets you optimize and create complex queries wh…
But how do you deal with refactoring? If I want to change a column on a db table or a property in a Java/C# class can the compiler tell me where I forgot to update without much ceremony?
This is a problem I had in the past on a large project. The result is that we devs started to get afraid of changing schema or code that touched database because that could create runtime errors as opposed to compilation errors. Being afraid to refactor is really bad and piles up quickly as technical debt.
Some ORMs solve this by scanning the database schema and creating a class per table and a field/property per column. This way we get compilation errors if database doesn't match code and have the opportunity to investigate it before it blows on the customer screen as a runtime error.
During my years as a dev i have really started to dislike ORMs. They always fail in the end. SQL is universal, and transfers between languages and tech fields. This is why im pro-sql, and always try to avoid unnecessary abstractions. I have actually went back to writing pure SQL in files, and using those as params for whatever db engine i use, this makes it even possible to reuse the code in other projects (even its…
I hate ORMs with the fury of a thousand suns. The problem is that I know SQL but now I have to spend a bunch of time trying to figure out how to convert SQL into ORM X just so it can convert it back to inefficient SQL. SQL mostly translates between various databases but ORMs are unique and you have to learn a new API for each one. I'm on a project using TypeORM and it has been fantastic at helping developers on my te…
Don't most ORMs have ways to do raw queries when needed?
As a JS and async/await outsider, just looking at the README example, can anybody please explain what's the reason to have the await prefix syntax at all? At this rate it's going to be all over the place. If the function is asynchronous, what's the difference for the caller? Can't it just be omitted?
As a JS and async/await outsider, just looking at the README example, can anybody please explain what's the reason to have the await prefix syntax at all? At this rate it's going to be all over the place. If the function is asynchronous, what's the difference for the caller? Can't it just be omitted?
Since `Promise` is a value itself, and it can be passed around, you can create combinators for them (e.g. wait for all promises in a list to settle, for any promise to settle, etc.) This can only be done in userspace of promises are a value themselves, and this requires a difference between `Promise` and `R`, and a way to (blockingly) turn `Promise` into `R`. That way is `await`.
As a JS and async/await outsider, just looking at the README example, can anybody please explain what's the reason to have the await prefix syntax at all? At this rate it's going to be all over the place. If the function is asynchronous, what's the difference for the caller? Can't it just be omitted?
If you omit await, the returned calue is a promise which you can keep for later, instead of waiting right now. Say you want to kick off something you know will take a while, do some ofher things (async or not), THEN wait for the original async operation. (Or even say, wait for multiple promises to finish)
const res1 = func1(); // async or not, wait for the result
const res2 = func2(); // async or not, wait for the result
let res3_p = promise func3(); // async function, but we want the promise