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

131–140 of 220 posts

Re: DenoDB

#131

Post by KptMarchewa »

lyind wrote: post #113
phplovesong wrote: post #59

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 have reached the same conclusion regarding ORMs after strugling with Hibernate/JPA for some time. At least for Java and Kotlin the awesome library jdbi ( https://jdbi.org/ ) implements a very useful hybrid approach. One creates DAOs and Repositories to abstract away the DB and map results and arguments to/from objects on the fly. All while retaining full control over the SQL and all mapping aspects. This way SQL an…

JDBI is amazing.

Re: DenoDB

#132

Post by justsomeuser »

elliebike wrote: post #116
phplovesong wrote: post #59

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 always feel weird about comments like this. Instead of discussing the merits of the actual project shared, we're going on a rant about whether or not ORMs are a good idea? It's like whenever someone shares something they made with Electron, and the comments are just Electron hate.

I think it’s useful to debate both the general concepts and specific implementations

Re: DenoDB

#133

Post by KptMarchewa »

bjt wrote: post #44
KingMachiavelli wrote: post #40

Earlier quoted context omitted.

What's the alternative? Are you saying it's better to use raw SQL or to use your own home grown convenience functions for creating tables, selecting rows, etc.? And once you have the data from the SQL database are you keeping it just in arrays/dictionaries? Or should it at least be mapped to a class structure? As someone dealing with a bespoke SQL schema and mix of in-house SQL translation layers for different DBs, w…

> What's the alternative? Not sure the parent comment would like it, but there's a middle ground between ORM and raw SQL that I consider a sweet spot. It's more of a "query builder" library that gives you language-appropriate constructs for building any SQL you like, but also provides more correctness guarantees than just writing raw SQL strings. SQLAlchemy's "expression" layer, for example, does this really nicely.…

For Java, JDBI is also great choice.

Re: DenoDB

#134

Post by brainless »

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 your model definitions (like a model Class) which define the data model as a set of tuples (field name and field type, which is a representation of SQL type) into instances that hold data in the native types of the programming language and "magically" convert them to the SQL types. It usually falls under the realm of meta programming and is not exactly a first-class feature in many languages.

I am totally not a language expert and perhaps did not articulate this well enough, but if you are curious just search a bit and try. Just my 2 Rupees.

Re: DenoDB

#135

Post by bartlomieju »

dang wrote: post #37
atarian wrote: post #15

The link and title made it seem like something official from the Deno developers but it's just a mirror for https://github.com/eveningkid/denodb

OK, we'll change to that from https://deno.land/x/denodb@v1.0.38 . Thanks.

https://deno.land/x/ is a service from Deno, but it's a registry for 3rd party modules. There's no need to change the URL

Re: DenoDB

#136

Post by KptMarchewa »

viraptor wrote: post #77
bobmaxup wrote: post #71

Earlier quoted context omitted.

Don't most ORMs have ways to do raw queries when needed?

Yes. It's often a false dichotomy. You don't have to make a decision 100% either way. Just write SQL when it's complicated enough for a query to be useful. And you can still use ORM to write that `foo = Foos.recent.for_user(id)` which happens in small variations many times in the app, where you gain nothing but typing practice by writing pure SQL.

With JDBI you can just write

  @SqlQuery("SELECT * FROM users WHERE id = :id")
  User find(String id);
and not use any of the ORM footguns.

Re: DenoDB

#137

Post by dansomething »

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…

> But how do you deal with refactoring?

We solved this problem by having thorough automated test coverage for all SQL queries.

Here's basic lifecycle of a test: 1) Create the test database 2) Migrate the database to the latest schema version 3) Insert test data 4) Execute the SQL query 5) Validate the results of the query

Re: DenoDB

#138

Post by KptMarchewa »

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…

>I have a small suggestion: please try ORMs in different languages.

I mean, I've done it and had entirely different experience. Starting from the entire premise of learning N different abstraction layers over one abstraction layer.

Re: DenoDB

#139

Post by nih0 »

Not to be too negative but I really appreciate Java's DataSources and other abstractions every time I see some python/node "connectors".

Re: DenoDB

#140

Post by smt88 »

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…

I've used ORMs for 20 years in Java, PHP, C#, JavaScript, TypeScript, Python, and Kotlin. I have pushed code to production with at least 10 ORMs, possibly more.

ORMs are a bad idea. They are a productivity killer. Do not use them.

I also used to think I'd find a "good" ORM because the early magic is so exciting and efficient. But for anything beyond a toy or proof-of-concept, they are more cost than benefit.

Some of them (e.g. TypeORM, Entity Framework) are literally not debuggable because they use some much configuration magic.

Just avoid them. Write SQL in SQL (or a query builder that compiles to SQL).

Post reply on HN