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

141–150 of 220 posts

Re: DenoDB

#141

Post by Sammi »

vinkelhake wrote: post #42

I've been using [1] which is SQLite compiled to WASM (what a weird world we're in now). It's got some limitations and caveats, but it's working well for my current modest needs. It's a pretty straightforward wrap of the SQLite API - no ORM. The advantage is that it doesn't depend on having anything installed. Just import and you're good to go. [1] https://deno.land/x/sqlite@v2.4.2

I'd love to see a benchmark between using this and a natively compiled sqlite. Just to see how much performance is lost to this convenience, so I can judge if it would be worth it in a concrete project for me.

Re: DenoDB

#142

Post by nescioquid »

KptMarchewa wrote: post #133
bjt wrote: post #44

Earlier quoted context omitted.

> 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.

I came to like the approach, but I got the impression that the dev team has never seen a breaking change they didn't like, so upkeep was painful. It's been a few years since I've used it, so maybe they've chilled out a bit.

Re: DenoDB

#143

Post by andrewmcwatters »

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 programming language.

I think you do yourself a disservice when you hide from it that you eventually have to face.

Re: DenoDB

#144

Post by viraptor »

KptMarchewa wrote: post #136
viraptor wrote: post #77

Earlier quoted context omitted.

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.

I posted an example which is not a simple lookup by id. It was specifically "Foos.recent.for_user(id)" because you can have multiple Foos, with a (reusable) scope `.recent` that you can use in other queries and a lookup for a given user which likely includes a join.

So sure, you can write this out as multiple simple queries, but do you really want to code the repeated query for every case of: Foos.recent.for_user, Foos.active.for_user, Foos.recent.by_something, Foos.recent.active.by_something? And what if you don't want a whole object in that case, but only one column? ActiveRecord for example has you covered with `.pluck(:single_column)` that you can append at the end without writing yet another full query.

Writing the simple stuff every time, you get footguns simply by repeating trivial code - that leads to copy-paste and forgot-to-change-one-of-them mistakes.

Re: DenoDB

#145

Post by js2 »

flakiness wrote: post #6

Looking at the dependencies, I realized that it is now common to implement database bindings purely in the host language (vs. using vendor provided C/C++ SDK.) Deno PG [1] and MySQL [2] does it. This makes sense considering Deno's security model. But Node libs do the same [3][4]! This also kinda make sense, as node-based JS has to be async most of the time. Still it's such a hassle. Anyways, kudos to both communities…

[4b] https://github.com/sidorares/node-mysql2

[4] doesn't use parameter binding; rather, it inserts escaped values into the SQL statement client-side in place of any "?" placeholders. [4] also doesn't support prepared statements. [4b] uses parameter binding, sending the SQL statement as is separate from the values, as well as supports prepared statements.

Re: DenoDB

#146

Post by markstos »

So, pick a database, use DenoDB and then use the lowest-common-denominator feature set of all the databases it supports.

There's a great parable from almost two decades ago.

Movable Type was a popular open source blogging platform that used an ORM and supported multiple database backends.

Wordpress only supported MySQL.

Remember Movable Type?

I hacked on both and preferred working with Perl and PostgreSQL but the ORM layer was a pain to use. Thousands of other developers apparently agreed, as the Wordpress extension ecosystem thrived and Movable Type bombed.

Re: DenoDB

#147

Post by hu3 »

dansomething wrote: post #137
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…

> 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

Tests are nice. But I see disadvantages with relying on them:

1) We now need 100% test coverage for queries. Forget one of them and the castle might fall on the client side. This can be mitigated with gatekeepers on CI/CD pipeline to ensure 100% coverage. But it's still quite the effort.

2) Our feedback loop for developing refactoring is now slower now since we need to run all tests to see what broke after a schema change. In contrast to an IDE giving compilation errors.

3) If we build SQL queries by composing them, which is common pattern for business rule validations, there will be many branches to be tested.

4) We won't have auto-completion of table and column names in the IDE. And if you mistype them your feedback is slower.

I say that as someone who went all in SQL query builders and composability in a project but when it grew large we were still afraid of changing schema despite having a very high test coverage.

Re: DenoDB

#148

Post by brainless »

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…

I am also very happy reading, writing and understanding SQL. My own side-product depends on that ability: https://dwata.com. It uses reflection of the underlying SQL, using an ORM based reflect library, generates a vector of the relations and state of schema and creates SQL on the fly.

But, would I recommend a team to start writing SQL by hand: No, absolutely not.

Re: DenoDB

#149

Post by midrus »

christophilus wrote: post #129
midrus wrote: post #128

Earlier quoted context omitted.

Every single time I've seen somebody not using ORM on something more complicated than a todo list side project, the alternative becomes an imposible to understand and maintain mess of joins, custom made query builders, manual computation of computed fields, custom calls to fetch related data and hand made crappy shell scripts to do schema migrations. Also, most of the times this happens to come always from ecosystems…

At least in node, there are migration tools that let you write vanilla SQL. My current project is ORMless, and I think it’s turning out just fine. Time will tell.

How many people are working on it and how big is your project?

Re: DenoDB

#150

Post by Aeolun »

markstos wrote: post #146

So, pick a database, use DenoDB and then use the lowest-common-denominator feature set of all the databases it supports. There's a great parable from almost two decades ago. Movable Type was a popular open source blogging platform that used an ORM and supported multiple database backends. Wordpress only supported MySQL. Remember Movable Type? I hacked on both and preferred working with Perl and PostgreSQL but the ORM…

Of course. Developers experienced enough to see the benefits of and understand an ORM will likely not be working on your average Wordpress site.
Post reply on HN