What ORMs have taught me: just learn SQL (2014) • Hacker News Board

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

#591

Post by carapace » Sat, Sep 21, 2019, 4:25 PM UTC

What SQL has taught me: Just learn Prolog.

"I'm seriously you guys." I was recently working with a Prolog-SQLite binding when it suddenly dawned on me that I should just skip SQL and use the Prolog engine directly as the DB. Modern Prolog systems can handle millions of records, for a lot of applications that's all you need. On the other hand they also have e.g. ODBC bindings.

SWI Prolog can internalize data in flatfiles "Managing external tables for SWI-Prolog"

https://www.swi-prolog.org/pldoc/doc_for?object=section(%27p...

There's also a Prolog graph database coming out in October: TerminusDB.

https://medium.com/terminusdb

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

#592

Post by timdev2 » Sat, Sep 21, 2019, 4:34 PM UTC

bpicolo wrote: post #590

pests wrote: post #244

Earlier quoted context omitted.

The PHP ORM Doctrine supports a custom SQL like language called DQL that integrates your defined model/relationships as well as converting it to the correct SQL dialect for your backing store. Queries look like: SELECT u FROM ForumUser u WHERE (u.username = :name OR u.username = :name2) AND u.id = :id Where ForumUser is your model. https://www.doctrine-project.org/projects/doctrine-orm/en/2....

If I remember right, it's hugely lacking in ability to interact with more complex data types in e.g. postgres, like jsonb

It's certainly limiting, though you can write (or find implementations[0] of) custom types[1] that can be pretty powerful (void where prohibited, limitations apply).

[0] https://github.com/martin-georgiev/postgresql-for-doctrine [1] https://www.doctrine-project.org/projects/doctrine-dbal/en/2...

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

#593

Post by mumblemumble » Sat, Sep 21, 2019, 4:52 PM UTC

moring wrote: post #463

mumblemumble wrote: post #234

Earlier quoted context omitted.

I think that this is true if you're writing your application in a way that requires object-relational mapping in the first place. And that's only necessary when you're trying to manage your data in the application in an object-oriented way. And managing your data in an object-oriented way implies more than just the simple fact of defining classes to serve as data records. Those classes can be entirely equivalent to a…

Two counter-points: (1) While treating a single SQL table as a distinct entity is a sin by your argument, I would argue that treating a set of tables as a distinct entity is not. I'm referring to what DDD calls an aggregate, e.g. a customer (address + email history + scoring + whatever tables), or an order (line items, shipping info, payment info, ...) Reading the comments here, I'm starting to wonder if some kind of…

A distinction that may seem like pedantry, but I think is actually the crux of the issue I've had with with ORM:

The problem is not in treating entities in the database as entities. It's in treating instances of classes in the application's memory space as local proxies for those entities.

You're on much firmer ground if you understand them as simple pieces of information derived from the state of those entities as of some point in time. Both in terms of ending up with a more internally consistent and robust approach to data (by virtue of removing some temptation to preserve an illusion that this data can be presumed to always be complete and up-to-date), and in terms of not artificially cutting yourself off from most of the power of the relational model.

You're right that this tension is somewhat resolved by just switching to using an object store of some sort. (NoSQL is far too diverse of a subject to treat as a single unit.) But it's a very particular sort of resolution, because it's a sort of least common denominator approach where you just drag the data store down to the level of the programming model. It strikes me as akin to resolving the difficulties in maintaining complex software in Perl by resolving to never let anyone write anything more powerful than a shell or CGI script rather than by looking for a language that will better support you for the long haul. It can certainly be a fine and reasonable choice. The problem comes in when people don't fully realize that that's the choice they're making.

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

#594

Post by collyw » Sat, Sep 21, 2019, 5:19 PM UTC

rmilejczz wrote: post #554

collyw wrote: post #549

Earlier quoted context omitted.

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.

I am trying to say that most of the home grown solutions I have seen have been pretty poor quality, and lack documentation especially. Do enough maintenance programing and you will understand.

If you do test and document your own stuff properly you are in a small minority. Why not release it for others to use?

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

#595

Post by nurettin » Sat, Sep 21, 2019, 5:21 PM UTC

cutler wrote: post #319

nurettin wrote: post #318

ORM is like a regex. When you use it, you've got two problems. The problem with having two problems is that we love solving problems! Yay OCD! So if an ORM doesn't let us do something, instead of just getting the work done with a couple of quoted SQL strings, we try bending the ORM to our will. I know I've done this with the entity framework. And when we do that, the perpetual debate starts all over again.

Why do I have two problems if I use a regex? "Programming Perl" and "Mastering Regular Expressions" were what drew me into programming in the early 2000s. Whilst ORMs are optional regular expressions are not so I don't get your point.

Pretty sure regex is not the only answer to parsing problems. Maybe it is for someone who has preferred using it for the past 15 years.

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

#596

Post by ThinkBeat » Sat, Sep 21, 2019, 5:22 PM UTC

Attained wrote: post #589

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 worked for a bit on a code gen based typescript postgres builder, but haven't had time lately to build it out - https://github.com/Sammons/morbid I really think typescript would benefit from a good solution to this.

I do like the code-gen solution a lot. You can create code that is far less bloated than a generic framework.

I am old fashioned. I like to start with the database schema and generate code from that. I make a change in the schema I regen the code. Thanks for partial classes in C# I can persist customizations between code-gens if necessary.

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

#597

Post by _8ljf » Sat, Sep 21, 2019, 5:34 PM UTC

JesseAldridge wrote: post #227

This was my position for a while. ORMs introduce a layer of magic which obscures what's actually going on under the hood. I decided I would just make raw SQL queries and handle mapping data explicitly. I quickly ended up with a lot of duplicated code. So then I thought, "Well ok, I should add a bit of abstraction on top of this..." I started coding some simple functions to help map the tabular data to objects. One th…

Query builders != ORMs.

A query builder carefully preserves the underlying relational and RPC semantics and exposes all of that to the user in an easier-to-use form. That’s just good cautious modest abstraction.

An ORM believes it knows way better than those dumb RDBs how a database ought to behave by ingeniously pretending that everything you’re dealing with is just nice simple familiar arrays of local native class instances. Which, like all lies, ends up spawning more lies as each one starts to crack under inspection, until the whole rotten pile catastrophically collapses under the weight of its own total bullshit.

And of course it goes without saying which of these approaches our arrogant grandstanding consequence-shirking industry most likes to adopt.

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

#598

Post by pleasecalllater » Sat, Sep 21, 2019, 5:42 PM UTC

pknopf wrote: post #278

bartread wrote: post #81

There's a sensible middle ground here, although I agree with the thrust of the message because using an ORM doesn't obviate the need to learn SQL - something I think a lot of developers forget. The other extreme from using an ORM "for everything" is using SQL "for everything", either via loads of handwritten ad hoc SQL, or stored procedures, UDFs, views, or a mix of all of these. This is just a different nightmare. A…

> A sensible approach blends use of an ORM with handwritten SQL where needed. In fact most ORMs will allow you to do things like build collections of objects from custom SQL anyway, so there's really no need to shy away from it. This is really where it's at. Seriously people. Nobody should be writing raw SQL. Give me just enough of an ORM/abstraction to give me type-safety, leave the rest at the door.

> This is really where it's at. Seriously people. Nobody should be writing raw SQL.

I think nobody should be writing comments here. They should be generated by some tool. So, please, be serious.

:)

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

#599

Post by kizer » Sat, Sep 21, 2019, 5:59 PM UTC

There is friction here because it’s at the meeting of two languages instead of implementation-interface, or implementation-service. People either try to hide the underlying SQL entirely on the one pole, or attempt to embed a SQL-like DSL within the primary language. I think that modern programming language ought to offer first class support for embedding other languages or DSLs - an idea behind Language Oriented Programming.

SQL offers the domain appropriate syntax, while the “host” language allows access to in-scope variables, functions, etc.

Of course there would be some more work in allowing a “mix” of two syntaxes. Another option is a query language as a subset of the language, sort of like C# and Linq.

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

#600

Post by SomeOldThrow » Sat, Sep 21, 2019, 6:20 PM UTC

mapgrep wrote: post #205

geodel wrote: post #79

Earlier quoted context omitted.

To me it is more of as Ted Neward describes "ORM is Vietnam of Computer Science"[1] "Although it may seem trite to say it, Object/Relational Mapping is the Vietnam of Computer Science. It represents a quagmire which starts well, gets more complicated as time passes, and before long entraps its users in a commitment that has no clear demarcation point, no clear win conditions, and no clear exit strategy." [1] http://b…

Ya I’ve heard this one a lot. It’s kind of funny to say and does humorously underline the complexity of the problem but people take it seriously. So to take it seriously for a second: There was no good reason to be in Vietnam; even taking the stated rationale as a given, which many people did not, it was a concern many levels removed from the actual safety or functioning of American society. ORMs in contrast achieve…

> ORMs in contrast achieve much more proximate goals — they solve a real problem and can measurably reduce the amount of code you have to write.

Why would you optimize for LOC rather than expressing the behavior you want well? In some situations sure—rapid prototyping—but that’s an odd assumption in a general case.