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

What ORMs have taught me: just learn SQL (2014)

wozniak.ca

Post reply on HN
Print view View original

551–560 of 654 posts

Re: What ORMs have taught me: just learn SQL (2014)

#551

Post by taffer »

shkkmo wrote: post #404
taffer wrote: post #302

Earlier quoted context omitted.

> What ORM do people use that influences the structure of their database? Hibernate and JPA encourage designing your domain classes first and then generate the DDL from that. > Also, the ORM allows me to specify models that are not only used for structuring the database, but also for validation of incoming JSON requests and easily serialize queries back to JSON. Postgres has great JSON support, does the ORM something…

> Hibernate and JPA encourage designing your domain classes first and then generate the DDL from that. This is a feature, not requirement or need of the ORM. It seems pretty silly to let the existence of a feature prevent you from making designing the structure of your DB correctly. > does the ORM something with JSON that Postgres cannot do? Postgres's json functionality is used for manipulating and querying data sto…

> I believe the poster is talking about deserializing and validating json from REST requests and serializing json for REST responses using the mapping defined for the ORM.

These are also things that the json functionality of Postgres can do. For example, look at to_json and json_agg.

Re: What ORMs have taught me: just learn SQL (2014)

#552

Post by gmac »

GordonS wrote: post #500
gmac wrote: post #467

Earlier quoted context omitted.

Agreed. Helpers (and indeed types) can make working with SQL an actual pleasure. You do need to learn the SQL, though. (My TypeScript/Postgres solution, in this vein: https://github.com/jawj/mostly-ormless/blob/master/README.md ).

I've never been a fan of codegen, but I think I could get past it for this library - it looks great! I love how it let's you use SQL, while taking full advantage of TypeScript's wonderful typing system to give you intellisense and compile-time checking. Reminds me a bit of the SQL type provider for F# (which I was amazed by when I first saw it in action). I really like the way the readme has been written too - it giv…

I've never been a fan of codegen, but I think I could get past it for this library - it looks great!

Good news. :)

Maybe we can agree that typegen smells less than codegen?

Reminds me a bit of the SQL type provider for F# (which I was amazed by when I first saw it in action).

I should look that up — sounds interesting.

Re: What ORMs have taught me: just learn SQL (2014)

#553

Post by collyw »

cturner wrote: post #502
setr wrote: post #255

Earlier quoted context omitted.

Tbh you could easily claim that the explicit goal, mapping to objects, is incorrect. The real value is to reduce the damage of the SQL language itself — the unnecessarily ordered clauses, the arbitrary inconsistencies in syntax, the worthless parser errors, the lack of any static typechecking — which cause so much code bloat and debug headaches. There are two reasons to use the ORM: to not learn SQL, and to generate…

> What we really need is a less shitty version of SQL. My view is the opposite. The power of SQL perpetuates a low-quality software culture. The root issue is a dev culture that can't see past databases. A lot of software design runs like this: (1) translate business patterns into a relational schema; (2) build interactions with that schema; and (3) as that gets harder, use SQL arcana and ORMs and views and stored pr…

I see the same problems but it usually caused by a reluctance to modify the database schema. Once you get comfortable doing that and keep your schema matching the requirements then it solves a lot of the problems.

Re: What ORMs have taught me: just learn SQL (2014)

#554

Post by rmilejczz »

collyw wrote: post #549
rmilejczz wrote: post #299

Earlier quoted context omitted.

An in house solution is almost always better than an external dependency

Lack of testing, lack of documentation and lack of use would be reasons that your claim is usually untrue. You can't Stack Overflow a problem and see if anyone else has encountered it before.

This is a terrible reply, what are you even trying to say? You can’t stack overflow a problem so don’t write your own in-house solutions? Lack of testing? We write our own tests. We write our own documentation.

It’s crazy to me how many people on HN are ignorant to the costs of third party dependencies and the benefits of in house solutions when building large applications.

Re: What ORMs have taught me: just learn SQL (2014)

#555

Post by rmilejczz »

nullspace wrote: post #303
rmilejczz wrote: post #299

Earlier quoted context omitted.

An in house solution is almost always better than an external dependency

Hah... I’m probably falling for Poe’s law here, but anyways... there are certainly cases where in-house is better than external dependency - specifically when your team knows the tech domain better than anyone external can... but in general well-maintained (preferably open source with a community, or a well funded company) external dependencies are almost always better. They usually would have the years of fixing edg…

They’re also tailoring their solution to be as generic as possible.

Having written OSS and also having written enterprise applications, it seems plainly obvious to me why a homegrown solution is preferred. Code developed internally is understood by the team (you may not understand the underlying implementation of a dependency), and can be tailored exactly to suit your needs (ignoring edge cases that aren’t relevant, removing unneeded features). And you never have to worry about maintainers disappearing, breaking changes being introduced, or bugged releases that you can’t do anything about.

I don’t mean to sound crass but how on earth could you think this is an example of Poe’s law? What’s so extreme about being a responsible developer? I didn’t say “every solution should be developed in house” (though I think most large projects would be better for it!) obviously there’s is a cost associated with in house solutions and you should gauge that cost to see if it’s worth it for your application. But if you’re going to be working with that application for years and years to come then I highly recommend trying to write your own code instead of relying on libraries.

Re: What ORMs have taught me: just learn SQL (2014)

#556

Post by rmilejczz »

tomc1985 wrote: post #422
rmilejczz wrote: post #299

Earlier quoted context omitted.

An in house solution is almost always better than an external dependency

Idunno man, my day job working Rails code uses a custom mailer and job queueing system and everytime I have to work with it I really wish they'd used ActiveMailer and ActiveJob

Like I said, “almost” always. Really the larger the application and the longer time you as a dev will work with it, the more meaningful it becomes to write your own solutions.

It’s really a balance, but I don’t think it’s a balance most devs consider and they really should.

Re: What ORMs have taught me: just learn SQL (2014)

#557

Post by mattrp »

i_am_nomad wrote: post #370
gernak wrote: post #349

Earlier quoted context omitted.

>You can (and should) use them for simple queries. This is not a very compelling argument to use ORMs. It is saying "it makes easy things easier". This doesn't really buy you much value. The simple things are already simple. Bringing in a very large, complicated external dependency to make simple things simpler, is not a good idea. >If you're loading data into objects then you're just creating your own personal ORM a…

This kind of doctrinaire thinking, this sort of broad and bold declaration, is the stuff of high-traffic blog posts but not good advice for real world developers. Django, just as an example, does a magnificent job with its built-in ORM. Millions of developers use it, and they are not all fools. A fool is someone who would set out to build a simple-to-intermediate CRUD web app by writing SQL.

I love Django’s orm. I wish Django would publish its orm as a separate library. Every time I see a flask / sqlalchemy app I think to myself: Gee you could have saved at least 2x the keystrokes if you’d just used Django.

Re: What ORMs have taught me: just learn SQL (2014)

#558

Post by talkingtab »

For simple cases it is almost always a good decision to use an ORM if you don't know SQL. The question is whether and how long the ORM shoe will continue to fit. Databases are essential for many use cases so the chances are that an ORM will not always work. So decide on that basis when to learn SQL. Maybe not today, maybe not this project.

The other issue is how central

Re: What ORMs have taught me: just learn SQL (2014)

#559

Post by scarface74 »

AdrianB1 wrote: post #485
scarface74 wrote: post #374

Earlier quoted context omitted.

If you have one table that you’re doing a query on, what types of optimizations are you doing to the query as opposed to the database - or even if you’re doing joins?

In general for one table an index helps, but we have almost no queries on a single table. The Query Profiler is telling what part of the query takes the most (CPU, disk reads) and that is the starting point. Tuning a single query can take hours, depending how slow it is and how often it will run. There is some information on Internet on query optimizations, look it up. There are also server side optimizations, specif…

Are you really doing OLTP transactions on a table with millions of rows that require complex searches or are you doing OLAP style reporting?

I don’t think anyone would suggest using an ORM for reporting, aggregating, etc. I would even go so far as suggesting using a different type of database/table structure - a columnar store and send data to a reporting database. A reporting query over millions of rows wouldn’t be real time anyway.

Re: What ORMs have taught me: just learn SQL (2014)

#560

Post by fastball »

fuzz4lyfe wrote: post #523
fastball wrote: post #492

Earlier quoted context omitted.

You don't validate incoming request types / values?

I validate at the point of use/when it matters. For example if I'm going to use a value in a query, because I'm using parameterized queries the type conversion to string happens implicitly so type doesn't actually matter. If I get 2 or '2' it all ends up as '2' and the database infers type by the column type. If I need something to be a integer and I don't trust the upstream system then you have to: int(*number*) At…

I gotcha. I work on a lot of user-facing stuff, so if the type is somehow wrong, I generally prefer to let the user know, which is a lot easier with models.
Post reply on HN