[HN Gopher] Show HN: Write universally accessible SQL, not libra...
___________________________________________________________________
Show HN: Write universally accessible SQL, not library-specific ORM
wrapper APIs
Author : ckmar
Score : 90 points
Date : 2021-08-10 14:32 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| 1MachineElf wrote:
| FYI, it's only for PostgreSQL.
| ldd wrote:
| This may sound odd, but I never understood using heavy classes
| with relational databases.
|
| I use javascript too, and at most I need a couple of HOF (higher
| order functions) to do most of the work I need.
|
| Then again, I do use typescript and its type system, so maybe I
| am not the target audience.
| cpursley wrote:
| I bounced when I saw the Class extends syntax.
| devwastaken wrote:
| Elaborate
| penthief wrote:
| Enforced class hierarchies are not very adaptable. A simple
| approach would expect records, a mapping function and the
| findOne, findList, findSet plumbing. There should not be a
| need to enforce a class hierarchy framework upon the
| integrating code.
|
| Somewhat counter intuitively, type hierarchies cause leaky
| abstraction layers.
| sparker72678 wrote:
| I mean, more power to you if this is something you want, but
| writing raw SQL is something I will never miss.
| purerandomness wrote:
| Why? Just like learning Emacs/vim, the time investment is well
| worth it.
|
| You get much more elaborate the more time you invest in
| learning, and the skills gained will still be valuable in 25
| years - as opposed to whatever subset of SQL the query builder
| _du jour_ would give you.
| smcl wrote:
| It sounds like the commenter knows SQL, so it's not like they
| want to avoid _learning_ it. I can only guess, but more
| likely they dislike the fact that you have to represent your
| raw queries etc safely as a string in your application's
| language - which isn't _hard_ but it does look a little
| ungainly and tends not to scale too well. As for the "du
| jour" part - is there that much churn and fanboyism in ORMs?
| spfzero wrote:
| Strings do give you the ability to copy them right into
| your code from the SQL console after testing.
| smcl wrote:
| While that is true, I think most queries would involve
| parameters of some sort, so those would need to be
| fiddled with at the very least after pasting to your
| code, plus you'd also want to format them so they don't
| look that out of place. And at that point you've likely
| got a single maybe-weirdly indented query that appears as
| a plain string, which is fine if you have just a couple
| but can get a little tricky if you have a larger
| application.
|
| I'm not super religious about this - a colleague and I
| were discussing Hangfire.io's SQL Server code which has
| inline SQL[0] and we ended up agreeing that it's fine -
| but if I'm writing an application with a SQL backend I'm
| _definitely_ leaning towards using something like EF in
| .NET
|
| [0] = https://github.com/HangfireIO/Hangfire/blob/master/
| src/Hangf...
| spfzero wrote:
| True about the params. I guess I've always put the
| queries in as "here" strings, so they do look out of
| place in the sense that the structure is different. In
| most cases the sql was in a file with a bunch of other
| "lowest" level db calls, so I kind of got used to that
| being the look of those particular source files.
|
| Looked at the Hangfire code and the last two methods
| there look a lot like what I used to do in the old C#
| days. Except I'd have whole files of db stuff like that,
| and other files for the C# code that called them.
| BiteCode_dev wrote:
| I've learned vim. It was not worth it. I'm more productive
| with vscode and nano.
|
| I know SQL, 99% of the time, an ORM is more productive, for
| the rest, I can still write SQL manually. It's not an XOR.
| chousuke wrote:
| I'm completely hopeless in nano because I can't for the
| life of me use the arrow keys for moving around, so I just
| end up typing random strings of hjkl/bw or whatever in the
| buffer until I realize I have the wrong editor and switch
| to some variant of vi so I don't fight with my fingers.
|
| One major advantage of vi is that it's always there (except
| on Windows :().
| desmondl wrote:
| I got pretty proficient at using vim in vscode, and
| personally for me the investment was worth it. It's great
| for working in HTML with chords like `va"p` (replace
| selection around quote with clipboard) and `dip` (cut out
| the contents inside this xml tag). YMMV depending on the
| type of work you do.
| sparker72678 wrote:
| I'm fluent in SQL, and even with ActiveRecord it's not always
| possible to escape having to write it directly, but I still
| don't like it.
|
| Writing raw SQL comes with all kinds of risks you can
| abstract away through nice ORM APIs, and with a good ORM API
| I find that it's much easier to clearly communicate intent in
| the code.
|
| YMMV.
| crooked-v wrote:
| Even sticking to "just" SQL without a true ORM, using a well-
| designed query builder instead of writing raw strings will
| save you from inevitable "oops, forgot a comma" bugs.
| bob1029 wrote:
| In my experience, writing "raw" SQL only sucks if your schema
| sucks and/or you don't have much patience for abstract thinking
| and building views to make common use cases easier.
|
| I much prefer being able to write a simple SQL query to deliver
| a piece of business functionality, especially if this is part
| of some configuration-time setup and not a code-time thing.
|
| It's also 1000x easier to discuss the implications of a
| particular SQL query with other non-wizards. Emailing my
| project managers C# method snippets is just going to return
| more questions to my inbox.
| spfzero wrote:
| Its really worth taking the time to learn well. Any library
| that abstracts that for you, is using some rules to create sql
| underneath, so knowing what its (probably) doing can give you a
| lot of insight when tracking down performance problems or bugs.
| And, suggest changes you can make to the schema, or stored
| procedures if necessary to improve performance as well.
| cabalamat wrote:
| In the readme you say:
|
| >This contrasts against traditional ("stateful") ORMs which use
| query builders (rather than raw SQL) to return database-aware
| (rather than pure) objects.
|
| >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.
|
| I don't know what you mean by "pure" or "purity" here, and i
| think an explantion would help.
|
| Also, in the code: db.one(query)
|
| "one" does not strike me as a particularly expressive method
| name.
| ptx wrote:
| "single" might be a better name. The Kotlin standard library
| uses that name for a variant of the "filter" method (on
| collections) that returns a single matching element or throws
| an exception if there are more or fewer.
| athenot wrote:
| I'm not familiar with it, but at first glance, "one()" stands
| in contrast to "multiple()". Either running a single query or
| running multiple queries in a request.
| zachrip wrote:
| It is used for the amount of objects returned (not the amount
| of raw rows returned, to be clear). Many orms have `findOne`
| or `findAll` methods that return an object or an array
| respectively. Just helps to make things more ergonomic and
| usually appends a LIMIT clause.
| athenot wrote:
| Thanks for the correction. I guess that validates the OP's
| point after all.
| ltbarcly3 wrote:
| I tried to do something similar with
| https://github.com/justinvanwinkle/Norm about 10 years ago. It
| hasn'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.
|
| Probably one of the best parts of Norm, and a big part of why I
| wrote it, is that it doesn't require you to have a hardcoded copy
| of the databases schema in your code, it just works like SQL.
|
| 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.
|
| I still maintain and update for my own use. Feel free to make
| suggestions or request features.
| spfzero wrote:
| Nice work!
| tomrod wrote:
| I mean, good luck when you are later porting to another DB
| system.
| setr wrote:
| How often does one even migrate DB's? I've always seen the
| advice, but other than an explicit goal of supporting SQLite +
| Postgres simultaneously, I've never actually ending up needing
| to move.
|
| And given that RDBMS's tend to do have roughly similar
| performance profiles, except when they have radically different
| profiles (e.g. switching from row to columnar, or unique
| optimizations eg GIS in postgres), there's not much incentive
| to be moving around -- unless you hit the end of the envelope,
| at which point you're probably looking at a re-design anyways
| if you're already looking at re-architecting it.
|
| And if you're switching to something with a different
| performance profile, you're going to be rewriting those queries
| anyways.
|
| Personally I stopped considering databases as "standardized" or
| swappable -- and using an ORM for hot swapping purposes I think
| might be as ridiculous as using a library for unifying web
| server frameworks (you can definitely do it... but your common
| denominator is fairly pathetic).
|
| The only scenario I've seen where one changes DB with an
| explicit goal of minor code changes is migrating from some
| legacy DB on some ancient version to something more modern
| (especially today, targeting a DB the cloud can auto-manage),
| where your ORM DB flexibility won't help you whatsoever
| zimpenfish wrote:
| > How often does one even migrate DB's?
|
| I've never seen it happen on a production system in ~20
| years.
|
| Might happen at the current gig but that's more down to
| "Firebase is junk for this job and we're rewriting everything
| anyway, might as well consider switching DB too".
| BiteCode_dev wrote:
| Not the point. The point is that people can then build db
| agnostic libs on top, so that several projects from
| different teams can use it despite using a different db.
|
| E.G: you can use django, no matter if you are a mysql or a
| posgreq shop and still use the entire ecosystem of apps.
| tomrod wrote:
| Lucky! I've done a few.
| mind-blight wrote:
| I've seen it happen once. Back in 2011, the company I was
| working for decided to switch all of their apps from MySQL
| to postgres. We had built everything in Django, so the
| transition was a lot less painful than it could have been,
| but it definitely wasn't free.
| chousuke wrote:
| My anecdata says once in two decades. I migrated a few simple
| Perl webapps some time ago, the oldest being 20+ years old or
| something? Not completely sure when it was created.
|
| I moved them from Oracle to PostgreSQL because we would have
| had to start paying for Oracle licenses ourselves. It's a
| very good reason to change databases.
|
| There was no ORM, so I just rewrote the queries to be
| portable and added some runtime branching in cases where that
| wasn't possible. PostgreSQL has an extension that adds some
| Oracle compatibility functions and views; that helped. The
| initial data migration went pretty nicely with ora2pg.
|
| For the largest (and most important) application I had the
| writing side duplicate writes to both databases so I could
| run two instances in "production" and compare their
| behaviour.
|
| It took a couple weeks of work and testing and then a couple
| months of observing that the new system works fine; the
| biggest pain was Oracle's '' = NULL thing and the lack of
| common SQL syntax for sequences; and the complete lack of
| tests, of course...
| spicybright wrote:
| I mean hell, I've seen so many libraries need upgrading
| every few years. Two decades is a fucking steal in terms of
| man hours.
| qrios wrote:
| > How often does one even migrate DB's?
|
| We (an insurance company in Europe) have around 200 DBs and
| half of them have been running for over 15 years. We need to
| migrate at least these to modern systems in the next 5 years.
| These new systems all come with their own ORM and RDBMS.
|
| Most of the longer existing institutions have the same
| challenges. But even new companies are in a similar
| situation. The main problem with ORMs always arises when the
| business itself changes and/or new requirements (e.g. GDPR)
| come in.
| spullara wrote:
| More often than not, you aren't porting. You are making the
| system work with more than one kind of database. When my
| first company was acquired and was built on PostgreSQL (which
| was designed to be hosted) the acquirer wanted an on-premise
| version that also supported Oracle. Using an ORM made that a
| relatively simple process with only a few annoying
| differences between the two databases. Specifically,
| treatment of strings (oracle empty string is a null string),
| booleans (no boolean type in oracle) and DDL (oracle doesn't
| have transactional DDL).
| FalconSensei wrote:
| > How often does one even migrate DB's?
|
| Never happened with me. Only used something different (or
| even a newer major version) when writing a new tool or doing
| a whole rewrite of a current tool. Which kind of counts as a
| new one, right?
| tonyarkles wrote:
| > How often does one even migrate DB's?
|
| I have had multiple clients who have _wanted to_ migrate from
| MySQL /MariaDB to Postgres, but afaik none have ever
| undertaken the Herculean effort to do so with the multiple
| years of slightly incorrect cruft that has accumulated in
| their old databases that have evolved over time.
| Zababa wrote:
| That makes me think, is there a tool or document about the
| intersections of features provided by DBs? For example, if
| you're building for Postgres and MySQL, is there a way to
| only use features supported by the two? Same for MySQL and
| SQLite, or Postgres and SQL Server?
| spockz wrote:
| In my experience you seldom switch databases. Sometimes you
| need (to start) supporting multiple.
|
| I'm really in favour of having tighter and clearer/cleaner
| integrations using technology specific features (eg
| PostgreSQL specific or gRPC specific) getting the most out of
| the tool than wasting potential for the eventuality that you
| might need to change it someday. As long as you stay open to
| the idea of having to change it all someday.
| thornygreb wrote:
| Done it once..in 20+ years accompanied by an entire re-write,
| so not often enough to care about this at all.
| dwohnitmok wrote:
| Over time I've come to see DB-independence as a benefit that is
| seldom realized and therefore not a strong point in favor of a
| given system.
|
| Data is generally far more valuable than application code and
| often times your database will far outlive your application
| code (and sometimes even your choice of programming language).
|
| Moreover if you're using DB-specific features rather than
| generic SQL, there's usually a strong business need driving it
| that would cause DB-specific coupling even in a supposedly DB-
| independent ORM.
| jcpst wrote:
| > Data is generally far more valuable than application code
| and often times your database will far outlive your
| application code (and sometimes even your choice of
| programming language).
|
| I agree with this. At my current company, we have stored
| procedures that are over 30 years old still running. The
| original application code was VB6, then VB.NET, and now there
| are C# NET5 services. There's also all kinds of other
| document stores, but that old SQL DB isn't going away any
| time soon.
| joppy wrote:
| How big of a concern is this? Nowhere I've ever worked has been
| concerned with the ability to swap the database for a
| completely different one, in the same way they are not
| concerned with the ability to swap whatever programming
| language is being used for a different one.
| MattGaiser wrote:
| I worked for an organization that used Oracle for relatively
| trivial applications. The difficulty of switching to MySQL
| and then later to Postgres convinced them to use an ORM going
| forward.
|
| Basically if your app might last 20 years (this one went
| online when I was 4) it might be a consideration.
| setr wrote:
| IME if you didn't use the DB -specific features, migration
| is painful, but not that much so.
|
| If you did use the DB specific features, you're screwed
| regardless of an ORM.
|
| NB: I work for a DB migration firm, specializing in
| legacy->modern -- where our usual customer has thousands of
| SP's that have to be migrated and an ORM would have saved
| you maybe 5% of the effort; so my experience is biased
| towards that level of difficulty.
| sumtechguy wrote:
| TSQL and PSQL ideas of a stored procedure are not really
| the same.
|
| If your SQL is mostly bound columns or some sort of ORM
| only then you can get lucky and just play the data type
| matching game. But most of the ones I have ever had to
| port was playing the 'rewrite these 300 stored procs
| again' game. They usually ended up in some sort of stored
| procedure for one of a few reasons 'they only knew how to
| do that', performance, that is what the senior guy wants.
| martijndeh wrote:
| In a type-safe environment I think you should just be able
| to switch your pur sang SQL builder to another dialect.
| Because of the type-safety you'll be able to find
| incompatibilities at compile time which makes the migration
| easy enough (ignoring data migration). This avoids creating
| a weird ad hoc SQL dialect trying to fit all the others in
| a single API.
|
| I work on Mammoth which is a pur sang Postgres query
| builder, see https://github.com/Ff00ff/mammoth.
| yobbo wrote:
| RDBMs have proved to have far more staying power than random
| ORMs for various fashion languages.
| _moof wrote:
| In my experience this is an overrated concern. And when it does
| happen, it's usually accompanied by a rewrite anyway.
| tomrod wrote:
| Mid and low tail risk applications, certainly.
|
| Some applications have regulatory requirements associated
| with them, especially retention, or otherwise serve critical
| needs areas.
| refactor_master wrote:
| > Some applications have regulatory requirements associated
| with them, especially retention, or otherwise serve
| critical needs areas.
|
| Which is why the choice ends up between "keep a legacy
| system older than the average age in the IT industry" and
| "take it apart and start over".
| _moof wrote:
| My experience includes government, consumer unicorns, and
| new vehicle development in aerospace. I'm familiar with
| highly regulated and exponential-growth settings.
| tomrod wrote:
| Me too! And my experience notes that it is exactly-rated,
| versus under-rated.
| zzzeek wrote:
| SQLAlchemy author here.
|
| I would just note that these two statements are contradictory:
|
| > The name pureORM reflects both that it is pure ORM (there is no
| query builder dimension)
|
| and then
|
| > Specifying all the columns is tedious; lets use
| BaseBo.getSQLSelectClause() to get them for free.
|
| the "getSQLSelectClause()" 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'd end up with a
| "pure" 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().
| ckmar wrote:
| Yeah, when you're doing the 1% of super complicated stuff,
| definitely don't use this (and opt for the underlying database
| driver directly). But when you're doing the 99%, it's great!
| Unlike with stateful ORMs, there is no temptation to do the 1%
| using some obscure orm methods and never heard of option
| params. Just write the sql.
| kstrauser wrote:
| I was handed maintenance of a database with _horrid_ schemas,
| like table_1 joined table_2 on "substr(table_1.foo, 4, 3) =
| upper(table_2.bar) and table_1.type = table_2.first_name", and
| crazy stuff like that. One table had an index on
| "upper(substr(purchase_id,1,1))". Another was indexed on
| "substring(table_3.xmlvars,'<KEY>(.*)</KEY>')". (I just looked
| up the old codebase and copied and pasted. These aren't
| exaggerations.) I had zero chance of fixing the schema because
| a giant legacy internal application was built with it, and I
| had to make my (new) application adapt to its schema instead.
|
| I spent a couple of months exhaustively documenting these
| relationships in the form of SQLAlchemy models, so that I could
| eventually write table_1.join(table_2) and have it do the right
| thing without having to remember (and implement!) that
| complexity everywhere those two tables touched. It was sanity
| saving, and for that I'm hugely grateful. Thank you.
|
| If you're starting with a brand new DB schema, shiny and pure,
| perhaps you can get away with hardcoding a bunch of SQL. I've
| rarely had that luxury, so query builders are one of my
| favorite things.
| capitainenemo wrote:
| Seems to me if there's a bunch of apps dependent on that
| legacy data, that cleanup could have been done more usefully
| and elegantly in the database with some views anyone could
| use.
|
| Or, if for some reason views couldn't be added (lack of
| access) a set of generic CTE includes?
| BiteCode_dev wrote:
| It's always the same with the anti orm crowd, they either avoid
| any wrapper and prevent having a standard api to build uppon
| and inspect, or they create a light wrapper that ends up being
| a poor badly tested and documented implementation of 1% of
| SQLA.
| gabereiser wrote:
| Took the words right out of my mouth. As someone who has been
| adamant about using orm's for the last 15 years, it shocks me
| to no end that an engineer (or group of engineers) think they
| can roll a DAO better than a battle hardened orm like
| SQLAlchemy, Hibernate, Entity Framework. It's hubris in the
| least and straight arrogance at best.
| spfzero wrote:
| What might actually qualify as hubris, is thinking you've
| discovered the best solution for everyone else's future
| problems.
| OJFord wrote:
| What do you do when what you want/need is not representable
| in the ORM?
|
| For example:
| https://stackoverflow.com/questions/65596920/use-django-
| subq...
|
| Composite types & triggers, for some other examples, are
| only (at least they are!) available via third-party
| plugin/'installed app's too. You cannot defer a Django
| unique 'constraint', because it happens to implement it as
| a unique index instead.
|
| That's just the few that come to mind.
| ckmar wrote:
| YOLO
| blacktriangle wrote:
| It depends what you're doing with the data. If you're
| trying to map into an object based view of your data, then
| yes ORMs have at least thought of most of the issues there.
|
| However if you'd like to view your relational data _gasp_
| relationally, then the ORM is a giant anchor around your
| neck.
| BiteCode_dev wrote:
| Good orms like sqla comes in layers, and the object
| relationships mapping is the highest one. You can use
| lower level layers as you need, and retain the benefit of
| a strong battle tested abstraction that gives you
| introspection and a standard API.
|
| Sometimes I use sqla just for the connection pool and
| session handling and dump raw sql in it.
|
| It's not raw sql vs orm, as usual it's use a spectrum
| with good use cases for each part of it, and you usually
| benefit from all of it. But orm have pareto value in my
| xp.
| blacktriangle wrote:
| ORMs only have value IF there's an object model you're
| mapping to. When working in a language that has good
| support for relational data, ie support for sets of
| heterogeneus maps, you can skip the whole object model
| and avoid the whole need for mapping in the first place.
|
| Ruby and Python in particular really missed the boat on
| this one. I feel like they cargo culted practices from
| Java rather than embrace the implications of their own
| langauge's flexibility.
| ad404b8a372f2b9 wrote:
| Isn't that what pandas does kind of? You can execute sql
| queries and get the results in a dataframe which is a
| dictionary with some convenience functions on top. Do you
| feel python could have gone further to take advantage of
| specific language features to improve that workflow?
| blacktriangle wrote:
| I was more taking shots at Django. pandas is a great
| example of doing things right imo and me ripping on
| python at large was more my web-dev myopia shining
| through.
| spfzero wrote:
| Right, OOP is sometimes not the best paradigm for the
| given problem. If you're using C# or Java, sure, ORMs fit
| right in. Ruby and Python, not to mention Lisp etc.,
| offer a multi-paradigm palette where forcing objects in,
| just to access relational data, just obscures things.
| ziml77 wrote:
| I guess a lot of people haven't seen the middle-ground.
| For me that's always been where I've sat with ORMs. It
| takes care of some tedious parts of getting data from SQL
| into my application without pretending that the
| underlying data isn't relational. SQLAlchemy and Dapper
| (.NET) have been great for this middle-ground usage.
| jrockway wrote:
| I personally prefer something like sqlx, where you just
| scan rows into structs. That's the tedious part of
| object-relational mapping, and the part that actually
| makes sense to automate.
|
| Generally, I think what people call ORMs try to do too
| much, and there is an impedance mismatch on many levels.
| Objects and relations don't map; objects are statically-
| defined at program compilation time, and relations are
| the result of a dynamic query. I think the reason that
| ORMs work in dynamic languages is that there isn't a
| rigid set of objects defined by the program; rather they
| can come and go during execution. So the problem becomes
| a problem later -- static analysis, editor tooling, etc.
|
| Lifecycles are also complicated. You can have your ORM
| return dumb objects that you modify and re-store, or they
| can be "smart" and updated the database automatically.
| The "dumb object" approach neglects database transactions
| (multiple writers could have already modified your cached
| copy), and the "smart" approach neglects the networked
| nature of your SQL server (you may need to retry, you may
| need to time out if the server goes down, etc.) by
| pretending that some server run by another company is
| actually your CPU's cache.
|
| Finally, I think it's very optimistic to write an
| application to support more than one database backend,
| which seems to be everyone's dream. Many have tried. Few
| have succeeded. I chalk it up as actually being O(n) work
| to support n databases. MySQL has some quirk that breaks
| Postgres's assumptions. Even the humble SQLite is
| different enough that is hard work to support as a
| secondary / test-only implementation. (I realized this, I
| think, when I debugged some code that worked in tests,
| but not in production. The tests used SQLite and did
| something like "insert into foo (boolean_value=1); select
| * from foo where boolean_value='t'". In Postgres, the
| inserted object is selected. In SQLite, it's not! That,
| to me, was the end of ever supporting two databases
| without the explicit requirement to do so. I'd still run
| my Postgres tests against Postgres and my SQLite tests
| against SQLite, though.)
|
| All in all, I don't get it. Start a transaction, scan
| into a struct, mutate the object, write it back to the
| database. Not much code is required. If your mutation
| operation is too long to run in a transaction (i.e., it
| reaches out to the network for something), then you
| really need a state machine, which you can easily
| implement in your relational data model.
| Scarbutt wrote:
| What is wrong with viewing the data relationally?
| blacktriangle wrote:
| Nothing at all, I'd argue working with relational data
| relationally is ideal. It was in response to the
| statement that anybody try to do their own data access
| layer is guilty of hubris.
|
| I'd say the bigger hubris is trying to shove relational
| data into object graphs and the challenges and pain of
| ORMs is proof of that.
| OJFord wrote:
| I'm quite anti-ORM, though I've never not used one
| professionally (just because it's already been there / not my
| decision), so that might be different if I did for a while. I
| do think _something_ 's necessary though, and it maybe is a
| bit arbitrary where we draw the line for what's an 'ORM'?
|
| For example, I really enjoyed using rusqlite for a little
| side project/personal thing, but found apart from anything
| else just the repetition of `(?,?,?,?,?,?)` any time I wanted
| to insert something was annoying, for example. I started
| working a bit on [0] .. I don't know if I'd call it an ORM,
| just so I didn't have to do that, and could write `Model {
| ... }.insert(&conn)` instead. But still write plain SQL
| queries, I just want easy mapping between db table and
| language 'model' struct/class; column and field/attr.
|
| [0] - https://github.com/OJFord/rusqlite-model
| chousuke wrote:
| I'm personally not that much against query builders, but I
| dislike things that try to hide the database. Any
| datastructure that transparently performs database queries
| as you access items in it goes swiftly in my "nope" pile. A
| reasonable exception can be made for streaming iterators in
| a statically typed context, though that has its own issues.
|
| I especially dislike "load" methods on objects since they
| hide what is potentially a very expensive operation behind
| something that looks cheap and is easy to call in a loop;
| what I want is to query data first and then load it into
| objects if needed rather than create objects for querying
| data.
| dec0dedab0de wrote:
| It's not really an either or thing. There are plenty of
| reasons to avoid an ORM. When I talk to python devs who don't
| like ORMs I recommend SQLAlchemy Core. It's all the most
| important parts without the ORM. In my experience most people
| against ORMs are not dead set on writing SQL by hand, they
| just don't like OOP. Of course there are some DBAs disguised
| as programmers running around, but they're more of an
| exception than the rule :-).
| gigatexal wrote:
| 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
| simonbarker87 wrote:
| 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.
| dyeje wrote:
| There is no good JS ORM, so it's for the best.
___________________________________________________________________
(page generated 2021-08-10 23:01 UTC)