Show HN: Write universally accessible SQL, not library-specific ORM wrapper APIs

I feel like one of the few JS devs who is happy to just write SQL. Inline or as a stored procedure I just don’t see how learning an ORM and all it’s issues and bugs is harder than learning SQL.

In the readme you say:<p>&gt;This contrasts against traditional (&quot;stateful&quot;) ORMs which use query builders (rather than raw SQL) to return database-aware (rather than pure) objects.<p>&gt;The name pureORM reflects both that it is pure ORM (there is no query builder dimension) as well as the purity of the mapped Objects.<p>I don&#x27;t know what you mean by &quot;pure&quot; or &quot;purity&quot; here, and i think an explantion would help.<p>Also, in the code:<p><pre><code> db.one(query) </code></pre> &quot;one&quot; does not strike me as a particularly expressive method name.

SQLAlchemy author here.<p>I would just note that these two statements are contradictory:<p>&gt; The name pureORM reflects both that it is pure ORM (there is no query builder dimension)<p>and then<p>&gt; Specifying all the columns is tedious; lets use BaseBo.getSQLSelectClause() to get them for free.<p>the &quot;getSQLSelectClause()&quot; is absolutely a query builder function. Building out the columns to select from is in fact where things get very complicated if you are for example using SQL aliases, selecting the entity from subqueries, etc. I would predict this method would have to be very complicated to truly be useful in such real world scenarios, so you&#x27;d end up with a &quot;pure&quot; ORM that still has a significant query builder, just one that has its own particular brand of awkwardness in that the textual SQL you write has to match up with the assumptions of getSQLSelectClause().

This may sound odd, but I never understood using heavy classes with relational databases.<p>I use javascript too, and at most I need a couple of HOF (higher order functions) to do most of the work I need.<p>Then again, I do use typescript and its type system, so maybe I am not the target audience.

IMO ORMs are an abstraction too far. I’d rather use a query builder. It gives you better control over the query if you must use such an abstraction. Of course I would much prefer raw SQL and then doing the mapping to objects and serialization myself but that’s not for everyone and yadda yadda move fast … startups etc etc

I tried to do something similar with <a href="https:&#x2F;&#x2F;github.com&#x2F;justinvanwinkle&#x2F;Norm" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;justinvanwinkle&#x2F;Norm</a> about 10 years ago. It hasn&#x27;t generated a lot of interest, but I find it quite useful to construct queries without having to learn the minutia of an ORM library, or even a SQL generation library.<p>Probably one of the best parts of Norm, and a big part of why I wrote it, is that it doesn&#x27;t require you to have a hardcoded copy of the databases schema in your code, it just works like SQL.<p>I put quite a bit of effort into making bulk inserts efficient, as well as making sure rows could be streamed from the database while buffering as few as possible in memory on the client.<p>I still maintain and update for my own use. Feel free to make suggestions or request features.

I mean, more power to you if this is something you want, but writing raw SQL is something I will never miss.

I bounced when I saw the Class extends syntax.

In this space but a little lighter:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;gajus&#x2F;slonik" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;gajus&#x2F;slonik</a>

FYI, it&#x27;s only for PostgreSQL.

I mean, good luck when you are later porting to another DB system.