Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DenoDB

github.com

Post reply on HN
Print view View original

171–180 of 220 posts

Re: DenoDB

#171

Post by sergiomattei »

andrewmcwatters wrote: post #143
brainless wrote: post #134

Every time we discuss an ORM project, someone is bound to complain about ORMs in general. I have a small suggestion: please try ORMs in different languages. A lot of the power of an ORM depends on the language. Your ORM may not be the same as my ORMs - Django ORM, SQLAlchemy, Pony ORM. Try them and you will know why. I will wait. From my limited understanding, the language needs to allow reflecting and manipulating y…

For me, ORMs are a sign one isn’t comfortable reading and writing SQL. I think this happens because in so many projects, commercial and hobbyist, you write queries a few times and then forget about it. So, it’s totally understandable. I was there once. I’m very comfortable reading and writing basic SQL now, and so I’d prefer to think in SQL when working with a database, and think about objects when I’m in a programmi…

Damn right! I'm not comfortable with writing nor reading SQL, and I avoid it usually when doing my projects.

I know SQL. I just don't care enough or want to write it. For 99% of the stuff I do, it's just easier to grab an ORM.

Re: DenoDB

#172

Post by tgeorge »

I've played with SQLAlchemy and Django's ORM in the past with Python but as of late I have been taking a liken to Eloquent while working with PHP's Laravel. It's always weird trying an ORM when coming from native SQL but I think eloquent might of found a happy medium as it seems flexible to me.

https://laravel.com/docs/8.x/eloquent

Re: DenoDB

#173

Post by throwaway894345 »

SomeCallMeTim wrote: post #155
andrewmcwatters wrote: post #143

Earlier quoted context omitted.

For me, ORMs are a sign one isn’t comfortable reading and writing SQL. I think this happens because in so many projects, commercial and hobbyist, you write queries a few times and then forget about it. So, it’s totally understandable. I was there once. I’m very comfortable reading and writing basic SQL now, and so I’d prefer to think in SQL when working with a database, and think about objects when I’m in a programmi…

I am super happy and comfortable reading and writing SQL. Give me the slightest excuse and I'll write up a wicked complex query that does exactly what we need to solve a particular problem. I simply also feel that having 100% type safety in your results (which you really can't do with SQL queries) is a huge bonus. Add in database portability for most of your operations (including between, say, PostgreSQL and MongoDB)…

> ORMs are tools. If you ignore the power tools you have available, you're going to end up as obsolete as someone who insists on still building houses or cabinets using only hand tools. Yes, of course it can be done. But it takes 100-1000x longer, and the results are often not as good.

I'm very skeptical that there are any productivity benefits to ORMs. Note you can forego the ORM and still use a query builder to offload details of SQL syntax and even abstract over multiple SQL syntaxes for different databases. Type safety is also orthogonal to ORMs--you can have type safety without an ORM or you can have ORMs that don't provide type safety (these are very common).

In my experience, any productivity that you might gain from an ORM is immediately swallowed by the time it takes to debug problems in the magical ORM layers (and then some). I could make an equally silly analogy that using an ORM is like using a bulldozer to build a house rather than carpentry power tools, but I won't because these analogies don't add any substance to the conversation.

Re: DenoDB

#174

Post by clivestaples »

tgeorge wrote: post #172

I've played with SQLAlchemy and Django's ORM in the past with Python but as of late I have been taking a liken to Eloquent while working with PHP's Laravel. It's always weird trying an ORM when coming from native SQL but I think eloquent might of found a happy medium as it seems flexible to me. https://laravel.com/docs/8.x/eloquent

I am just discovering Laravel and years of Rails, React, etc and it's been a lot of fun. At first glance, DenoDB also seems to have a good level of abstraction.

Re: DenoDB

#175

Post by TranquilMarmot »

hu3 wrote: post #74
TranquilMarmot wrote: post #32

Earlier quoted context omitted.

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…

I love SQL and being able to squeeze performance from these magical blackboxes called database servers. 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 co…

> 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

Yes, this definitely happens! Like somebody else said, tests can cover a lot of this. But of course they aren't perfect.

Where I'm at right now, we have multiple microservices reading from the same database so schema changes are a terrifying nightmare ("which service will break when we remove this column?!"). Unused columns have piled up over the years; in our `users` table we have almost a dozen unused columns. Onboarding new folks is always fun; "No, you don't want to look at the `role` column, you want to look at `role_id`!" Note that this issue would still be a problem if we were using an ORM (unless we had a shared library between all microservices that are talking to the database )

I've used ORMs extensively before and they do make refactoring a little bit easier, but I still would rather write raw SQL. Basically personal preference at this point; if I were to join somewhere that was using an ORM I would learn it and probably be happy with it!

Re: DenoDB

#176

Post by prirun »

SomeCallMeTim wrote: post #162
pionar wrote: post #152

Earlier quoted context omitted.

Why not? If you're going to use a tool (be it SQL, NoSQL, docker, kubernetes), your team needs to have/build some expertise in it. IMHO, using something like an ORM abstracts that layer. It also introduces a "black box" into your ecosystem. Going by my opinion in the first paragraph above, you'd have to build some expertise in this ORM. Why spend that time when you can just spend time getting to know your data storag…

Because "getting to know your data storage technology better" isn't the business goal. On the surface, that's a great goal to have, but taking an approach that requires you to do 100x as much work so you can learn SQL better isn't software engineering. It's over-billing. I throw together 200 lines of schema in Prisma.io and it creates 20,000 lines of GraphQL handling code plus more ORM-specific code that allows me to…

I develop a backup program, HashBackup. It uses SQLite. I wrote all the SQL. Most of the SQL stmts are a few lines long.

Another backup program, Duplicati, uses SQLite. Sometimes they post SQL that is having problems, and one query will go on forever, like 50-100 lines of SQL. Duplicati is written in C# so I'm guessing (but don't know) that it uses some kind of ORM. Figuring out why a 100-line SQL statement was slow would be very unfun.

Not intending to dis Duplicati; just saying that black boxes are only good if they work 100% of the time, and my experience is, they don't. And any black box you can reverse engineer in an hour is not giving much productivity gain IMO.

Re: DenoDB

#177

Post by dragonwriter »

TranquilMarmot wrote: post #175
hu3 wrote: post #74

Earlier quoted context omitted.

I love SQL and being able to squeeze performance from these magical blackboxes called database servers. 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 co…

> 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 Yes, this definitely happens! Like somebody else said, tests can cover a lot of this. But of course they aren't perfect. Where I'm at right now, we have multiple microservices reading from…

> Where I'm at right now, we have multiple microservices reading from the same database

Like, all from the same base tables or each with their own schema with service-specific views? Also, isn't shared-DB integration by-definition incompatible with “microservices”, which are isolated and sovereign over their own data?

Re: DenoDB

#178

Post by Scarbutt »

brainless wrote: post #164
pionar wrote: post #152

Earlier quoted context omitted.

Why not? If you're going to use a tool (be it SQL, NoSQL, docker, kubernetes), your team needs to have/build some expertise in it. IMHO, using something like an ORM abstracts that layer. It also introduces a "black box" into your ecosystem. Going by my opinion in the first paragraph above, you'd have to build some expertise in this ORM. Why spend that time when you can just spend time getting to know your data storag…

By that logic, I should also know compilers, lexers, kernel, and the whole pile of protocols that run the Internet in a great amount of details. Where do you draw the line? We need abstractions. Sure some abstractions are leaky, others are simply not good. But that is exactly why people should try to make better ones.

SQL is a high level language, more declarative and better at manipulating data than your project's programming language.

Comparing a compiler implementation would be in this case comparing to a database implementation.

Re: DenoDB

#179

Post by hn_throwaway_99 »

zomglings wrote: post #119
hn_throwaway_99 wrote: post #14

Earlier quoted context omitted.

You're being downvoted, but I completely agree. If you are on Node and Postgres I highly recommend using slonik - it makes it easy to just write SQL but at the same time makes it almost impossible to have mistakes like SQL injections: https://gajus.medium.com/stop-using-knex-js-and-earn-30-bf41... https://github.com/gajus/slonik

The "Stop using knex.js" blog post misses a very important point in favor of using knex.js: database migrations. Migrations allow a development team to synchronize database schema changes across multiple branches of development. It is the main reason I end up using tools like knex.js (node) and sqlalchemy (python). As far as knex is concerned, you can use it to manage migrations without using it in your application c…

I don't really think that blog post misses that, I just think that DB migrations functionality is very different from SQL builder functionality, and that blog post is referring to the SQL builder part of this.

FWIW, I do use knex for migrations, but I hate the SQL builder part of it, so most of my migrations are littered with knex.raw statements.

This was discussed at length in this slonik issue, https://github.com/gajus/slonik/issues/42 , with some recommendations for migrations functionality.

Re: DenoDB

#180

Post by andrewmcwatters »

sergiomattei wrote: post #171
andrewmcwatters wrote: post #143

Earlier quoted context omitted.

For me, ORMs are a sign one isn’t comfortable reading and writing SQL. I think this happens because in so many projects, commercial and hobbyist, you write queries a few times and then forget about it. So, it’s totally understandable. I was there once. I’m very comfortable reading and writing basic SQL now, and so I’d prefer to think in SQL when working with a database, and think about objects when I’m in a programmi…

Damn right! I'm not comfortable with writing nor reading SQL, and I avoid it usually when doing my projects. I know SQL. I just don't care enough or want to write it. For 99% of the stuff I do, it's just easier to grab an ORM.

Yep. It’s good that these options exist.
Post reply on HN