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

To ORM or Not to ORM

eli.thegreenplace.net

Post reply on HN
Print view View original

281–290 of 300 posts

Re: To ORM or Not to ORM

#281

Post by djupblue »

davidcuddeback wrote: post #36
localhostdotdev wrote: post #25

rails g model Post published_at:datetime title content:text rails g model Comment post:references author published_at:datetime content:text rails g model Tag name rails g model PostTag post:references tag:references class Post from there it's just regular rails: Tag.find_by(name: "something").posts Post.joins(:tags).where(tags: { name: "something" }) Tag.create(name: "something") Post.create(...) Tag.first.posts made…

You forgot to add an index on tags.name and null constraints on the rest of the columns. > from there it's just regular rails That's the problem. Examples like this focus on the first few minutes of development. Not the subsequent years of maintenance.

Adding an index on tags.name is likely not very useful on its own but adding an index with an uniqueness constraint to prevent duplicates is probably a good idea. Assuming there are just a few different tags records (>Not the subsequent years of maintenance.

I'd much rather maintain this example than a code base replicating the same behavior without an ORM.

Re: To ORM or Not to ORM

#282

Post by vinceguidry »

oogway8020 wrote: post #273
vinceguidry wrote: post #54

Earlier quoted context omitted.

> Not the subsequent years of maintenance. You're gonna have to pry the Rails from my cold dead fingers if you want me to maintain a web app's database abstraction layer long-term. No other tool works half as well as ActiveRecord. You could maybe convince me to try out https://rom-rb.org/ but only on a brand new project and only if Rails isn't appropriate. If it's a project that wasn't built with Rails, I'm going to…

I have been lucky to be able to pick what I want to use, so I pick non-rails stack (Sinatra/Padrino and now Roda + Sequel). No other tool works as half as Sequel. You're gonna have to pry Sequel from my cold dead fingers.

Don't get me wrong, I love Sequel. But ActiveRecord is far more polished. And that starts to matter once you start needing to go 'off-script'.

Re: To ORM or Not to ORM

#283

Post by dblohm7 »

bunderbunder wrote: post #97

I've come to a couple conclusions, over the years. First, when you get down to it, the most-valued feature of ORMs is not the "writing queries in some language other than SQL" feature, it's the "not having to write a mess of mapping code" feature. Second, the biggest drawbacks to ORMs all derive from the "writing queries in some language other than SQL" feature. Fortunately, there are tools out there that solve the "…

I completely agree. Having worked on both a database execution engine, as well as on the application side, you could not get me to write queries in any language other than the database's native query language.

Re: To ORM or Not to ORM

#284

Post by btilly »

polygotdomain wrote: post #168
btilly wrote: post #133

Earlier quoted context omitted.

I have spent enough of my life untangling a mess of views that create performance problems to doubt that views are maintainable. Also, there is usually no good solution for keeping the database in sync with code releases. With the result that database+code change synchronization tends to be a source of deployment complexity. Keeping the logic in one place is better than the alternative. And of the two, the tools to m…

>I have spent enough of my life untangling a mess of views that create performance problems to doubt that views are maintainable. Just like concepts like inheritance can be a burden when overused, views can be overused as well. Like inheritance, having views go too many levels deep generally winds up causing more harm than good. Used correctly though, views are able to capture and centralize concepts in a way that ar…

In the common setup where there is a central database shared by developers, you really can't keep the database in sync with all of the code. Furthermore the manual nature of keeping things in sync means that there will be errors. Hopefully those are caught in staging, but I've seen this not always work.

Re: To ORM or Not to ORM

#285

Post by leowoo91 »

Liking to write SQL can easily make you think ORM is tend to have more mistakes or become out-of-control, but in fact, you can fix certain bottlenecks later and combine with raw queries without having to get non-ORM overall.

Re: To ORM or Not to ORM

#286

Post by gremlinsinc »

I like to mix orm/non-orm.. for anything involving multiple joins and more complex stuff I'll just write raw sql...

Using laravel as an example I'll usually make a $sql var to hold, then just run DB::select(DB::raw($sql))); It still keeps things nice and succinct, I let DB handle some of the setup/connection boilerplate, and I just figure out the sql myself, but for 80% of the time I rely on Eloquent..

The benefit of relying on Eloquent is I tend to like to 'tie' into the event system, so for example you have to explicitly be aware when adding/deleting a user that might have other related tables created at the same time as 'setup', you can tap into the 'creating/created/saving/saved/etc' events and when a new user is 'created' you could create a profile for example.

For me I think the killer feature is keeping an event cycle when it matters, sure you can explicitly remember to update/map everything when you code your sql, but is everyone on the team going to do that? If you for example update profile>fullname whenever user->firstname or user->lastname is updated, it's easy using an orm. not so much when 15 different devs are updating things in different places in different ways using sql only. Everytime ->save or ->create( is called it handles the events you put in play. (This is just an example, I'd probably just do a setter or getter to grab the first/lastname and combine them instead of having duplicate data, but again this would only work if you're using eloquent to grab the data in the first place, because it's model related)

Re: To ORM or Not to ORM

#287

Post by karmakaze »

rhlsthrm wrote: post #241
karmakaze wrote: post #209

Earlier quoted context omitted.

I've come to the same conclusion from using a number of query and relation mapping frameworks (e.g. Rails, Spring). I've finally decided to write one that solves the problems that I have with them. It comes down to just a few things: 1. Embrace SQL 2. Handle the ON clauses for JOINs 3. Fetch relations of sets of records (eager or lazy at the call site) in batches without making N+1 queries 4. (bonus) async composabil…

This is great, this is exactly something I've been looking for. I'll definitely look into using this for my next project.

Thanks for the validation. I was beginning to wonder why this hasn't been done already and maybe I'm the exception rather than part of a group who need/want it.

Re: To ORM or Not to ORM

#288

Post by karmakaze »

ksec wrote: post #270
karmakaze wrote: post #209

Earlier quoted context omitted.

I've come to the same conclusion from using a number of query and relation mapping frameworks (e.g. Rails, Spring). I've finally decided to write one that solves the problems that I have with them. It comes down to just a few things: 1. Embrace SQL 2. Handle the ON clauses for JOINs 3. Fetch relations of sets of records (eager or lazy at the call site) in batches without making N+1 queries 4. (bonus) async composabil…

Have you consider posting this as Show HN?

Yes that's my intention soon. I'm still dogfooding for a while to shake out its design warts. This post was so fitting I had to mention it.

Re: To ORM or Not to ORM

#289

Post by GordonS »

strokirk wrote: post #182
GordonS wrote: post #178

Earlier quoted context omitted.

I don't like to say "you're doing it wrong", but TBH it sounds like you are. > restricted to SQL structures So is your ORM; it just adds a layer of abstraction > require absurd hacks or custom dlls Literally no idea what you're doing that views require anything out of the ordinary, or indeed "custom DLLs" > not properly source controlled Eh? You can store your view DDL files in source control just fine. I mean, they'…

What SQL GUIs do you use that draws graphs for EXPLAIN statements? The ones I've used for OSX (PopSQL, Sequel Pro, TablePlus) hasn't had that feature. Haven't used MySQL Workbench in a few years, so not sure about that one.

I mentioned SQL Server Management Studio (SSMS), which is a great GUI for SQL Server. There is also pgAdmin (both 3.x and 4.x have this feature), and it's also available in Azure Data Studio (for SQL Server; it's coming soon for the Postgres version).

Re: To ORM or Not to ORM

#290

Post by GordonS »

rawoke083600 wrote: post #252
GordonS wrote: post #172

Earlier quoted context omitted.

I'm very comfortable with SQL, but I also like the static typing and compile-time safety that linq brings. Automatic migrations I like less. In particular, Entity Framework and Entity Framework Core migrations. Firstly, it seems that the second you stray from the most basic of scenarios, thry generate incorrect DDL. Secondly, I'm just not a fan of 'magic' code gen. Thirdly, every entity/model change a dev makes does…

Damn that's a lot of enterprise level words and acronyms to just "store some data". Lol not saying you wrong... just don't like this part of our industry. Is it too late to go back to Turbo Pascal (record-files) ? :)

Not sure I really mentioned much 'enterprise-level', beyond SQL Server?

I guess I'm making it sound more complicated than it really is then, because this approach is actually a lot simpler than the 'N-tier' abstraction-hell of yesteryear.

Jimmy Bogard has a simple example here: https://github.com/jbogard/ContosoUniversityDotNetCore

Some code can probably explain it better than me ;)

Post reply on HN