Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flyweight: An ORM for SQLite

github.com

Post reply on HN
Print view View original

51–60 of 105 posts

Re: Flyweight: An ORM for SQLite

#51

Post by metadat »

metadat wrote: post #16
uup wrote: post #13

Earlier quoted context omitted.

You would really like sqldelight[1] then. It takes the concept of an ORM and flips it on its head. Instead of mapping function calls to SQL statements, it lets you write SQL statements and then generates classes for you that have methods for those statements. For instance, you could have a SQL statement like getCardsForFight: select * from fights where cardId = ? and titleFight = ?, and it would generate a class that…

Note: sqldelight currently only supports generating classes for Kotlin. With something like this existed for Golang!

*Wish

Re: Flyweight: An ORM for SQLite

#53

Post by mgkimsal »

tyingq wrote: post #43

I don't like ORMs much, admittedly mostly because I did a fair amount of development with SQL before they existed. But, there was one that I played with that did have appeal to me, RedBeanPHP. Forgetting that it's PHP for a minute...that's not the main point. It was cool because it had a fluid way of working. It automatically generates the database, tables and columns... on-the-fly, and infers table relations based o…

I loved redbean for a while. Sort of a mix of 'nosql' up front, but it's being baked in to a relational DB. I did a number of small projects extremely quickly with redbeanphp. You're making me want to go explore it again :)

EDIT:... well... I see it's still got an aim of being PHP5 compatible. Upgrades for PHP 8.1, but that seems off a bit. I seem to remember composer was an issue... and there still is. Impressive that the author is still evolving and supporting it :)

Re: Flyweight: An ORM for SQLite

#54

Post by dimgl »

astrobe_ wrote: post #45

I've heard that ORMs are the "Vietnam" of CS [1]. The article is pretty old, is it still the case? [1] https://blog.codinghorror.com/object-relational-mapping-is-t...

Yes. Yes it is. So much so that I will, as much as possible, try to not use an ORM that creates queries for me.

Simple ORMs that map columns in rows to attributes or properties in an object are fine. ORMs that handle complex relationships and migrations and the rest (a la Entity Framework, Hibernate, ActiveRecord), are all pretty much a vote of no confidence from me in any project.

Re: Flyweight: An ORM for SQLite

#56

Post by SadWebDeveloper »

Kinda prefer Prisma when working with js/node or ts /deno but might try it if i need something more lightweight than prisma for a new toy project.

As for the ORM debate, not applicable for SQLite but if m using a database with better support for stored procedures (like sql server, postgresql or oracle), i just prefer a minimal DAO or an ORM that just built from stored procedure calls.

Unfortunately sometimes, specially in a big diverse team we do prefer an ORM so devs focus on other things a let the DBA guys try to guess why my code calls select everytime it refers to "entries" object just to get one entry.

Re: Flyweight: An ORM for SQLite

#57

Post by randomdata »

MichaelCollins wrote: post #4

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

ORM is orthogonal to SQL. The purpose of ORM is to transform relations (sets of tuples) to object graphs and back again. ORM toolkits provide some kind of declaration method to describe how that mapping should occur to save you the slog of doing it by hand.

SQL is the usual mode for receiving those relations, and so many ORM toolkits also include query builders to help with that level of abstraction, but theoretically an ORM toolkit could require you to write SQL in the raw.

Re: Flyweight: An ORM for SQLite

#58

Post by bob1029 »

ORM 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 those other areas, you can begin to dispense with the frameworks and resume more ownership over these areas.

Surrendering a little bit of control up-front makes a lot of sense when you are trying to work through a difficult & new problem. I would definitely prefer the computer do some sub-optimal, blind-mapping of my objects until I could settle on a final schema. Managing a bunch of raw SQL queries while your relational model is still in flux is not something I would look forward to.

Re: Flyweight: An ORM for SQLite

#59

Post by sgt101 »

mrweasel wrote: post #36
MichaelCollins wrote: post #4

const 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're coming at it from a slightly wrong angle. You are completely right that for queries, there's really no gain, you just end up having to learn both SQL and whatever your ORMs DSL is. Where ORMs are useful is once you have your objects. The usefulness of an ORM is being able to say: user.email = 'new@example.com' user.groups.append('admin') user.save() Also being able to work on your data in objects or structure…

I've never bought this :

why not

user.updateGroups('new@example.com','admin')

Sure you have to write the updateGroups method and use SQL to do it, but that's trival. On the otherhand when you want to do something more complex this is when ORM's inject all sorts of subtle and dangerous bugs into your code base.

I've had some terrible experiences with them...

Re: Flyweight: An ORM for SQLite

#60

Post by lambdafourtwo »

bob1029 wrote: post #58

ORM 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 complexity when it comes to optimizing SQL.

You optimize SQL with hacks to get it to compile into an efficient query. With an ORM you have to hack the ORM in order to hack the sql in order for it to compile into an efficient query. It's nuts.

The fix for this problem is to not use an ORM. You want to use in language primitives? Make an abstraction that is one to one with SQL. A library that gives primitives that directly represent SQL language primitives. That's what we actually all want. We don't actually want an orm.

Post reply on HN