41–50 of 105 posts
Earlier quoted context omitted.
What’s a good solution for that without a classic ORM?
Conditional text interpolation with named parameter bindings works quite well. We’ve basically abandoned the ORM for select queries at work as we find this approach more readable.
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.
I'm with you on that. I use ORM's, yet, being perfectly comfortable with SQL my perspective ends-up in a range between "this complexity isn't worth it" and "why not just write this in SQL?".
One of the arguments for ORM's is being able to move to different db engines. Frankly, I can't remember the last time I had to do that for a mature/released application.
Once again, I'll admit my perspective is biased because SQL isn't a problem for me. When I look at ORM code it looks and feels very detached from the database. I look at SQL and everything is clean and clear. In addition to that, you don't have to create and manage a bunch of objects that take-up memory and slow things down. Adding layers of abstraction isn't always the best idea.
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 on naming conventions and how you interact with code. No config files at all.
So, you would iterate in dev solely by writing code, and end up with a schema including foreign relationships. Then, you can "freeze" the schema for prod, turning off all the dynamic stuff.
Their quick tour explains it well: https://redbeanphp.com/index.php?p=/quick_tour
Note: I'm sure it has notable downsides over time, but the approach was really nice starting from scratch.
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…
[1] https://blog.codinghorror.com/object-relational-mapping-is-t...
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…
But .NET also has Dapper where it lets you write all the SQL and then it just handles the binding of data into objects, which having that handled for me is great.
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…
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…
But, yeah, that's not the normal path.
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…
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 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 code, so long as you're not using provider specific extensions.
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.
If you work on a large application with lots of transactional processing, it makes sense. I've worked on apps with 10's of 1000's of lines of Ibatis scripts. And on applications where you're expected to just invoke stored procedures for every little operation. I'll take Hibernate over that situation any day.
People really overstate the pitfalls of ORM's. If you're running reports against a data warehouse, don't use an ORM. If you are trying to optimize a complex query, don't use an ORM. For an app that is write heavy, with very many simple updates to a complicated object graph, it makes sense.
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…
Also tests: https://gist.github.com/johndoe46/17eacf0f12772dfb870732479b...
(This is proof of concept quality, don't use for real work)