Aren't ORMs supposed to give you one way to interact with a DB over different SQL dialects? Doesn't an ORM for one dialect defeat the purpose of an ORM?
Flyweight: An ORM for SQLite
81–90 of 105 posts
Re: Flyweight: An ORM for SQLite
#82Here's a python (pip) version of the same concept: https://github.com/Aperocky/sqlitedao https://pypi.org/project/sqlitedao Same concept, huge speed boost to personal projects. ORM is great because you can abstract items in memory directly into persistence, and define the relation in programming language instead of SQL.
This doesn't look the same at all. The point of flyweight seems to be use code generation based on sql code; sqlitedao seems to be more like a normal orm.
Re: Flyweight: An ORM for SQLite
#83Earlier quoted context omitted.
I said it once many years ago and I still say it: "ORMs are for people who don't know SQL" However, I understand the problem it tries to solve: Object-Relational Impedance Mismatch. I only wish there were other idioms, not the convolution of classes and mappers.
I've never said this before but I'll say it now: "'ORMs are for people who don't know SQL' is usually said by people who have never written a complex application." I agree that ORMs are dangerous and clumsy for a number of use cases, but the query-building aspect is indispensable in many scenarios. Unfortunately, the query builder is usually tightly coupled to the ORM, but _if you do know SQL_ then you can use the OR…
You can have a query builder without an ORM.
Re: Flyweight: An ORM for SQLite
#84If I'm reading this correctly, it doesn't handle object graph traversal - if you need it, you have to write your own JOIN manually, and then the library will wrap that. I would argue that graph traversal is one of the basic features of an ORM.
Re: Flyweight: An ORM for SQLite
#85const fights = await db.fights.get({ cardId: 9, titleFight: true }); translates to select * from fights where cardId = 9 and titleFight = 1; Confession: something about ORMs has never clicked with me.. none of them ever seem simpler than SQL.
You are missing the steps to get that select statement into JavaScript (running the database command, passing in the parameters, parsing the result, etc).
Re: Flyweight: An ORM for SQLite
#86If I'm reading this correctly, it doesn't handle object graph traversal - if you need it, you have to write your own JOIN manually, and then the library will wrap that. I would argue that graph traversal is one of the basic features of an ORM.
In an ORM, you will write
include: ['posts']
join posts on p.authorId = a.id
Re: Flyweight: An ORM for SQLite
#87Earlier quoted context omitted.
That is an atrocity on so many levels. For one, you're creating a hard coupling to a specific flavor of SQL. And that's not too mention the fact that you're taking an otherwise purely data object and embedding persistence logic into it - a horrifying abuse of OO.
> you're creating a hard coupling to a specific flavor of SQL. I fail to see why this is a problem. Switching databases is a costly move, and is pretty rare as far as I know. When it does happen, it is usually from one type of db to another type, not between two RDBMSs. IMO it doesn't, by itself, justify sticking to an ORM rather than raw SQL.
Switching databases can be an easy move depending on how you design schemas, versioning and migration. We have a multi-cloud, multi-db offering - customers choose their DB. Without ORM, this would not be feasible.
Re: Flyweight: An ORM for SQLite
#88ORM is usually a bad idea if you are trying to reduce the overall complexity of a solution. Only in the happiest of cases does an ORM solve all of your problems without creating a multitude of new ones. My experience with ORMs is very similar to my experience with web frameworks. I view them both as a way to offload cognitive burden while you learn about other aspects of the problem space. Once you reach mastery in t…
People usually switch to ORMs because they want to use in-language primitives for their application of choice. It's jarring and inelegant to switch between SQL and javascript or something like that. The problem with an ORM is that it's a high level abstraction On top of what is ALREADY a high level abstraction: SQL. ANd it's not even a one to one abstraction... they are very different and this actually adds more comp…
> Make an abstraction that is one to one with SQL
Which SQL?
Re: Flyweight: An ORM for SQLite
#89Earlier quoted context omitted.
With SQLite, I've started using json_each on a JSON parameter for bulk inserts or updates. Other SQL databases should have something similar. It's much cleaner than generating SQL, and doesn't run into issues with exceeding the maximum number of parameters.
This sounds very neat. Do you have an example handy?
This is what I do in postgres:
insert into your_table(id, created_at, uri, project_id)
select id
, created_at
, endpoint as uri
, project_id
from jsonb_to_recordset($1)
as x(
id uuid
, created_at timestamptz
, endpoint text
, project_id uuid
)Re: Flyweight: An ORM for SQLite
#90Earlier quoted context omitted.
ORMs where you don't write sql make me nervous, though it doesn't help the main version of this I used was raw linq-to-sql (not Entity Framework), and it could be very hard to convince linq to generate the correct sql for what I was doing (I once had to write my relationships backwards else it kept generating sub queries). But .NET also has Dapper where it lets you write all the SQL and then it just handles the bindi…
I had a positive experience with Linq2db: https://github.com/linq2db/linq2db I mention because I had something of the opposite experience with it. It not only ended up yielding the correct queries, but I saw a significant increase in performance. And the neat thing about it, beyond ORM and linq-to-sql, is a common interface amongst providers - so you can do things like swap from SQLite to Postgres with 1 line* of cod…
Huh interesting. If I ever do any personal projects that need a DB I'll have to take a look at this. Appreciate the link.