In my career, I have used Entity Framework, Active Record, Sequelize.js and Hibernate. I haven't had a problem with any of them. Especially not with postgres and mysql. I've worked in teams of 10+ and personal projects that I've completed in a couple of days. My advice is to only use the best of ORM's. I won't use an ORM unless it's at least 5 years old.
What ORMs have taught me: just learn SQL (2014)
601–610 of 654 posts
Re: What ORMs have taught me: just learn SQL (2014)
#602Earlier quoted context omitted.
So you do all your analytics by running a series of service calls and then writing a script to collate them into the needed results? Seriously?
I'm not the GP, but yes, absolutely. There are plenty of things that make this less than awful: - The existence of tools that allow structured access to multiple APIs (GraphQL is a nice middle ground between "YOLO any queries you want" and "you only get row-by-row access exposed by the web APIs"). - The existence of data on multiple internal data stores. Analytics folks usually are not prepared to engage with the com…
Forcing analytics to go through the API doesn’t actually reduce load on the production DB, it just increases load on the API itself. Step 1 should probably be a dedicated read replica and step 2 should probably be an ETL process.
Re: What ORMs have taught me: just learn SQL (2014)
#603Earlier quoted context omitted.
Sorry, maybe I wasn't being clear. I don't just validate that the request is JSON, I validate that the fields in the JSON are valid fields to send over the wire. I do this by automatically hooking my ORM models into my request validation. If a request doesn't specify a column that is NOT-NULL, for example, it will automatically send an error response telling the client that it needs to specify that column in the requ…
Python doesn't have type safety to begin so those sort of checks have less utility to me and since json.loads returns a dictionary and python objects are effectively dictionaries you are pretty much done.
Python doesn't force type safety but there benefits of being type safe to ensure things stay valid/bugs are caught/defense in depth for malicious requests.
Re: What ORMs have taught me: just learn SQL (2014)
#604Earlier quoted context omitted.
Right, so let’s suppose you already segmented the data to two different backing datastores, and your monolith is now connecting to both of them instead of just the one. Now you can do the service migration, at which point you still run into the situation I’m discussing.
Cutovers are hard, to be sure. Ideally they should also be short (the time time a service undergoing mitosis spends talking to the old and new locations should be measured in days or hours or less). Don't choose general data access patterns for the infrequent occurrence of cutover. Cutover is when you break a few rules and then immediately stop doing so. Build for everyday access patterns instead (which should be thr…
Stored procedures are a better API than arbitrary SQL. You may even be able to enforce it by granting EXECUTE permissions but not SELECT permissions.
Re: What ORMs have taught me: just learn SQL (2014)
#605Earlier quoted context omitted.
In terms of wiki syntax, HTML is just so damned noisy that I'm fine with Markdown--but mostly because Markdown is fairly standardized and I don't have to learn a totally different syntax for everything.
"Fairly" So I spend as much time faffing about with how this particular tool does anchors as I would just doing the "a" tag outright in HTML.
The real question is why aren’t you using the WYSIWYG editor most wikis have these days.
Re: What ORMs have taught me: just learn SQL (2014)
#606Earlier quoted context omitted.
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...
Yeah, the missing bit was custom operator support if I remember right.
Re: What ORMs have taught me: just learn SQL (2014)
#607Earlier quoted context omitted.
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…
Just keeping the lights on in manufacturing plants with thousands of sensors and counters monitoring the production. Just data collection is useless if you don't put it on good use and that requires some aggregation and correlation to tell what is going on on the floor.
Re: What ORMs have taught me: just learn SQL (2014)
#608Earlier quoted context omitted.
There is a big difference between just writing helper functions to construct SQL and convert data types, and OO-style magical auto-persisted objects. The latter is what I don't like about ORMs but the former is fine. I feel that this is an important distinction to make. As an example, the sqlalchemy docs[0] make this very clear: there's an ORM, but there's also just a core expression library that simply helps you con…
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'm not even someone that has used multiple orm styles extensively, but it is disturbing/darkly humorous how many orm libs there are.
That lastpost you can map a half dozen Java frameworks to each of the acts.
Personally I never found an orm that tracked which attrs in objects were actually mutated so that only mutated columns would be updated/inserted, but again I never did a lot of orm.
Re: What ORMs have taught me: just learn SQL (2014)
#609Earlier quoted context omitted.
Why not? I've used hand rolled pseudo ORMs before. I prefer just plain SQL but for the application I had there was a common access pattern that was worth abstracting out in a DRY sense. That doesn't mean I want or need a complete ORM. Just a consistent access at certain table types.
I’ve never seen a homegrown ORM that was better than a third party one. Whenever there is an issue - and there are always issues - you have to dig into the code, because they are never documented well. There is usually a feature that no one thought about and then you have to make modifications to the custom ORM and you get an even bigger mess.
Better is a subjective term.
I wouldn't say what I built was a better ORM. But I would 100% say it's a better solution to the problem I faced.
It didn't get in the way of writing SQL, but it did reduce the boilerplate and repetitive gruntwork.
"Issues" - no, it was a function call deep and incredibly clear and close to what was happening.
Re: What ORMs have taught me: just learn SQL (2014)
#610Earlier quoted context omitted.
Out of curiosity what platform and tech where you using? I am making the assumption of a predominately OO one based on the virtues of ORM. I have always found that when I try to solution back end or middleware based platforms with OO dominate languages (read Java, C#, et. al.) that there quickly becomes an impedance mismatch and any communication with the database becomes a monster of mapping OO philosophy to relatio…
> I find the converse to be true for the front end. I find most attempts to deal with the UI in anything other than objects and components (read jQuery, React Hooks), turns to spaghetti rather quickly. What alternatives have you tried?
ClojureScript, Reflex, Grapefruit, Seesaw and a host of others, It's my opinion (so take it with a grain of salt) and it very well may be the way my brain works but I just find functional to not marry well to UI development. For the service and process oriented stuff associated with the front end I think it is great, but when it comes to modeling components, I find objects and inheritance work far better.
This is one of the reasons I have long been a huge proponent of Javascript despite it warts, as it can be OO when I need it to be OO and functional when I need it to be functional.