So this ORM positively surprised me, as you can still just use SQL and get a JS function generated from it.
To bridge object-to-relational mapping, Oracle has an interesting concept called "JSON duality views". Don't dismiss it because it is Oracle, I think the concept is brilliant. The translation from relational to JSON happens in the database, and it also allows you to send an updated JSON back and the DB will automatically run the necessary DML operations. A good example is here: https://oracle-base.com/articles/23c/json-relational-duality...
perl's DBIx::Class ORM had a rule from day one of "if you can't get the exact same SQL you'd've written by hand, that's either a bug or a missing feature" and close to two decades on people who've moved to other languages still regularly tell me they miss that aesthetic.
Which is a way to write SQL in Java. (with type safety too)
Mongo just doesn't feel like that. Every example I have seen is simply "KV lookup". No discussion of things like range based queries, or how data relates to each other. Yes of course these things are possible, but it requires writing a imperative query. Seems like it encourages people to be lazy and duplicate data everywhere, which results in a poor data model.
Why would we dismiss the number one feature we have been asking database vendors to implement for the past 20 years just because Oracle happens to be among those vendors?
You can get something similar in SQLite with normal views and triggers using JSON1 functions, but it would be a lot of effort to create those triggers manually.
reminds of kysely typed SQL builder which was perfect to use with postgres in one of my previous projects.
I currently am working on a sqlite based project but based on Tauri's sqlite connector which is plain SQL.
Is there anyway I can make use of Flyweight in Tauri based projects?
I just use kysely for my sqlite-in-browser project.
This might be the answer to an unusual date bug I noticed years ago but haven't prioritized fixing in a personal project. TIL!
I have used pgtyped for postgres, and missed not having something similar for sqlite. This library seems to perfectly fill the gap.
I don't want to learn/remember a new way to query the same underlying database every time I switch projects/stacks/etc... sql is better, literally.
But why would anyone use an ORM that is specifically to one database? For me, using an ORM is the ability to switch between databases, specifically SQLite for testing and PostgreSQL for production, without having to change any logic.
It is database agnostic. It works with sqlite, mssql, mysql, postgres, oracle, and sapase.
It gives you full intellisense without code generation - even when running pure javascript.
You can run it from the browser in a secure manner, as you can host it in express js via adapter.
I am the author.
I wonder if there’s a type system strong enough that it can actually parse files, send remote queries, etc… so that types will be generated on the fly as you type with no additional steps.
I heard TS’s and other languages’ type systems are Turing-complete, but surely they’re all isolated enough that this wouldn’t be possible?
Seems like it would be pretty cool. Also kind of a footgun, since the type system becomes a program of its own.
I know a lot of devs treat database schemas as sacrosanct and try not to modify the schema much once created. However, I do like being able to iterate on schema quite a bit during early stages of application and in case of dot-star queries I often end up with either run time errors or type errors that are quite far from the query itself. So now I have settled on ensuring that all columns are always specified in queries originating from application code.
Just use SQL on both ends
"SQL IS OLD AND ISN'T A REAL LANGUAGE WRITE ACTUAL CODE WITH PANDAS OR SPARK" in the middle
I'm getting old :(
https://www.reddit.com/r/datascience/comments/s0dn5b/2022_mo...
