SQLite 3.40 Released With WASM Support For Web Browsers, Recovery Extension

[patrick1946]

Well I'm not that familiar with sqlite, can you elaborate on that or points me to where I can read about this?

Have you looked into https://www.sqlite.org/optoverview.html? It gives you a overview of the optimization Sqlite does. It explains to that you have to call ANALYZE to provide data for them. You can compare that to other Sql databases.

[NobodyXu]

Have you looked into https://www.sqlite.org/optoverview.html? It gives you a overview of the optimization Sqlite does. It explains to that you have to call ANALYZE to provide data for them. You can compare that to other Sql databases.

Thanks, I would have a look at that.

[BrokenAnsible]

Yeah, I do dislike SQL. With SQL you are writing database-specific SQL since every database server has slightly different SQL language so with a ORM you abstract that way and make the code more portable.
The ORM's query planner probably optimize better than most people.
With a ORM you can have the compiler ensure that the references columns and tables actually exist, everything is strongly typed.

I love ORMs and am glad I don't have to deal with raw SQL too often.

ORMs aren't magic wands and SQL engines aren't equal. It seems you want everything to look like a nails because you like to use hammers.

[uid313]

The same restrictions apply to any combination of databases and languages and ORM libraries. Databases only have generic types whereas your app code might use whatever custom classes. If you have to convert a database into app code, you already fucked up a long time ago.

In my experience reverse engineering a database to code with Entity Framework Core can work really good. You get .NET datatypes for the things, it's great.

So you want your mappings to be generated automatically from the schema.
I get it, but making a few adjustments when working with SQLite doesn't seem a major drawback, considering that you should check the generated classes anyway...

The problem with making adjustments is when you have a change to your database schema and run a reverse engineer again you lose all your adjustments.

ORMs aren't magic wands and SQL engines aren't equal. It seems you want everything to look like a nails because you like to use hammers.

No, ORMs aren't but Entity Framework Core is pretty damn amazing!
It is incredible what you can do with, how much you can configure it, and how you can bind your models to your database entities, even have smart objects and apply domain-driven design (DDD).

[JackLilhammers]

uid313
Wouldn't be easier to make the changes on both sides? Again, you're going to check the autogenerated mapping anyway

[BrokenAnsible]

In my experience reverse engineering a database to code with Entity Framework Core can work really good. You get .NET datatypes for the things, it's great.



The problem with making adjustments is when you have a change to your database schema and run a reverse engineer again you lose all your adjustments.


No, ORMs aren't but Entity Framework Core is pretty damn amazing!
It is incredible what you can do with, how much you can configure it, and how you can bind your models to your database entities, even have smart objects and apply domain-driven design (DDD).

So... what you are saying is that your hammer is .NET specifically the Entity Framework. Congratulations on literally proving my point. You don't have to buzzword bingo me about DDD either. EF and other ORMs do not have a monopoly on DDD especially when you don't need the 'save' feature when implementing CQRS on a event sourcing system. You know what you can do with SQLite and a thin pure SQL layer? Insert only event sourcing logs on small devices that will call home when they get a network connection (IoT use cases). Why would we use ORMS to do that?

[uid313]

So... what you are saying is that your hammer is .NET specifically the Entity Framework. Congratulations on literally proving my point. You don't have to buzzword bingo me about DDD either. EF and other ORMs do not have a monopoly on DDD especially when you don't need the 'save' feature when implementing CQRS on a event sourcing system. You know what you can do with SQLite and a thin pure SQL layer? Insert only event sourcing logs on small devices that will call home when they get a network connection (IoT use cases). Why would we use ORMS to do that?

No, my hammer isn't .NET and Entity Framework. It's just one of many languages I code in. I also code in Rust, Kotlin, Python, PHP, JavaScript, TypeScript and more.

I am not buzzword bingo when I mention DDD, the reason I mention it is because with DDD you do have a complex domain object that is a challenge to map with a ORM which is why many resort to just just taking in the database entities as parameters to the constructor of the domain object instead of actually using the domain object as the database entity and have the ORM map it.

I know EF don't have a monopoly on on DDD, you can do it with Hibernate on Java too, but my personal experience with EF Core has been great.

I am not saying SQLite is bad, it is great for use cases like you mention, a IoT embedded small device or as storage for desktop applications (like Firefox use it for bookmarks).