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

To ORM or Not to ORM

eli.thegreenplace.net

Post reply on HN
Print view View original

271–280 of 300 posts

Re: To ORM or Not to ORM

#271

Post by bpyne »

marcosdumay wrote: post #151
bpyne wrote: post #105

Earlier quoted context omitted.

"and because SQL is impossible to compose without substantial problems." Would you mind providing an example of what you mean?

A few features that I miss on SQL that hinder composition: - A good module system - View-like variables - Scoped singletons (related to the module system) - First class functions - First class symbols (that can be used as object names) - Composable queries (related to the view-like variables and first class symbols) If I wasn't on vacation I would have a few more fresh on memory. Different ones each day.

Ah, I see what you mean. I was thinking in terms of union'ing and the like where you can use set theory to compose sets of information from various queries.

Re: To ORM or Not to ORM

#272

Post by bunderbunder »

thoman23 wrote: post #258
spion wrote: post #208

Earlier quoted context omitted.

Would that be a "RRM" (Record-Relational mapper)? If so we're already on board (in a different language). P.S. I bet you would never guess which typed language with great support for records makes it easy (for the most part) to build most type-safe SQL queries on the fly, even with projections, without explicitly defining types for every possible projection variation.

I get that you're talking about Typescript, but I just want to say that Scala excels in this area as well. I found Slick to be a pleasure to work with once I embraced not trying to map directly from a relational model to an object model, but instead to just use Scala's ability to manipulate and reshape the relational model as needed.

I've come to appreciate that model, too.

Somewhere in one of his talks, Rich Hickey goes on this great mini-rant about, "Why can't we just let data be data?" I wish I could remember exactly which one it is. Maybe "Simple Made Easy"?

Re: To ORM or Not to ORM

#273

Post by oogway8020 »

vinceguidry wrote: post #54
davidcuddeback wrote: post #36

Earlier quoted context omitted.

You forgot to add an index on tags.name and null constraints on the rest of the columns. > from there it's just regular rails That's the problem. Examples like this focus on the first few minutes of development. Not the subsequent years of maintenance.

> Not the subsequent years of maintenance. You're gonna have to pry the Rails from my cold dead fingers if you want me to maintain a web app's database abstraction layer long-term. No other tool works half as well as ActiveRecord. You could maybe convince me to try out https://rom-rb.org/ but only on a brand new project and only if Rails isn't appropriate. If it's a project that wasn't built with Rails, I'm going to…

I have been lucky to be able to pick what I want to use, so I pick non-rails stack (Sinatra/Padrino and now Roda + Sequel). No other tool works as half as Sequel. You're gonna have to pry Sequel from my cold dead fingers.

Re: To ORM or Not to ORM

#275

Post by marcosdumay »

bpyne wrote: post #271
marcosdumay wrote: post #151

Earlier quoted context omitted.

A few features that I miss on SQL that hinder composition: - A good module system - View-like variables - Scoped singletons (related to the module system) - First class functions - First class symbols (that can be used as object names) - Composable queries (related to the view-like variables and first class symbols) If I wasn't on vacation I would have a few more fresh on memory. Different ones each day.

Ah, I see what you mean. I was thinking in terms of union'ing and the like where you can use set theory to compose sets of information from various queries.

Well, I'm not the OP. AFAIK, he may be thinking the same as you.

SQL lacks some power on negative and consolidated joins, forcing one to write more complex queries than necessary. It is this way for good reasons, because those are exactly the kinds of joins that indexes help you least and that most hinder parallelism, so they should be avoided if possible. On my experience, it's not a large drawback, but YMMV.

Re: To ORM or Not to ORM

#276

Post by GFischer »

Dayshine wrote: post #167
dragonwriter wrote: post #130

Earlier quoted context omitted.

> Say for instance we have one query that finds eligible bachelors near me and another that finds newly eligible bachelors. We need two queries but they both rely on the same underlying domain concept of "eligible bachelors". [...] It's hard to do that in sql in a maintainable way. Seems a textbook case of using a view for sharing query logic. > If I decide to change a datetime field called time to split it into a da…

>Seems a textbook case of using a view for sharing query logic. Views are just terrible outside of data analyst style work. Unmaintainable, restricted to SQL structures, require absurd hacks or custom dlls, not properly source controlled, difficult to perform performance analysis on, hard to update. You can't combine views easily, you can't cache results, you don't get static type checking.

At least for MS SQL, code is fully source controllable, I have it on Git and we have all automated deploys and niceties.

Views can be a problem from a performance side, Oracle has materialized views but MS SQL lags behind (I think Postgre has them too).

Re: To ORM or Not to ORM

#277

Post by stickfigure »

pjmlp wrote: post #263
stickfigure wrote: post #260

Earlier quoted context omitted.

If you have a trivial app that just executes a couple queries, then sure use JDBC? I do not understand your point. Most business apps are not trivial.

Who said anything about it being a trivial app? It was an ETL stack for distributed networking monitoring, and data reporting.

If you can comfortably use JDBC for data access, then your data access logic isn't very complicated. There's nothing wrong with that; use the right tool for the job.

Re: To ORM or Not to ORM

#278

Post by pjmlp »

stickfigure wrote: post #277
pjmlp wrote: post #263

Earlier quoted context omitted.

Who said anything about it being a trivial app? It was an ETL stack for distributed networking monitoring, and data reporting.

If you can comfortably use JDBC for data access, then your data access logic isn't very complicated. There's nothing wrong with that; use the right tool for the job.

Who said it wasn't complicated?

Using SQL with JDBC isn't a synonym for bare bones string concatenation.

Offload complex queries to external files, or better yet, stored procedures.

Re: To ORM or Not to ORM

#279

Post by hardwaresofton »

gmac wrote: post #126
hardwaresofton wrote: post #65

While I learn towards not using an ORM, the productivity gains (at the very least early on in development) are undeniable. What I've always looked for are frameworks that give you an ORM but also make lower level queries very easy, normally via a query builder, allowing you to go back and forth between levels of abstraction. If I had to choose, I prefer libraries that give you the lower level of abstractions first an…

I loved TypeORM initially, but came to the conclusion that it was written by people who really got TypeScript, but didn't really get SQL. For example, we were converting from Sequelize, where we were catching unique constraint violations and responding appropriately, and we got quite confused that in TypeORM those errors never got thrown ... until we discovered that TypeORM decides unilaterally (and almost unbelievab…

I've never had this problem (constraint violations result in errors for me) -- did you file a ticket?

Like others have said, I'd also love to see if you've written anything about this!

How do you deal with queries that are slightly formulaic & different or need to be assembled dynamically? do you use any query builder at all?

Re: To ORM or Not to ORM

#280

Post by toast0 »

collyw wrote: post #171
toast0 wrote: post #4

Earlier quoted context omitted.

All the time allegedly saved is also more than compensated for when the ORM makes bad queries that are roughly impossible to fix.

Most ORMs allow you to write SQL, no? So why not just use that when appropriate?

So, I'm the 'database guy' and I come in when the DB is on fire. I find the bad query(ies) and tell the application developer they need to do it another way. (And suggest ways)

Then they tell me, it's too hard / impossible to do something else, and that's after it took them two weeks to figure out how the query is formed.

For these applications, it's best to ensure their DB is isolated from other DB needs and let the tire fire burn as a signal to others, because I can help a lot with performance, but adding indexes can only help so much.

When I've had similar experiences with people running bad queries from strings, it's a lot easier to get traction on fixes. Even when they think my suggestions are crazy (nobody likes it when I suggest a client side join, however, sometimes it's significantly faster)

Post reply on HN