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

251–260 of 300 posts

Re: To ORM or Not to ORM

#251

Post by rawoke083600 »

Apart from the well thought out and "proper arguments" like "You don't know what queries it does underneath...". Its usually the "insane-funny-sub-language" you have to learn to work the said ORM which only works for 50% of the queries before you really have to get weird with it.

My not correct and sub optimal solution over the years is to have some sort of "god-class" that has a big collection of sql-related queries with some query-reuse(error checking etc) like "student_insert_update(namedList,namedValues)"

or "student_get_all_subjects(student_id,semester)"

I know its not perfect :/

Re: To ORM or Not to ORM

#252

Post by rawoke083600 »

GordonS wrote: post #172
ozim wrote: post #111

Earlier quoted context omitted.

Actually "writing queries in some language other than SQL" which has static typing and catching issues in compile time is quite big for me. Add automatic database migrations that are also keeping types in line with code and whole bunch of "mess of mapping code" goes away. Though I use .NET EntityFramework which by now is really mature and heavily invested into by MS. Not sure how it is with other environments but I t…

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) ? :)

Re: To ORM or Not to ORM

#253

Post by ivolimmen »

stickfigure wrote: post #196
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 "…

Fortunately, there are tools out there that solve the "mapping tables to objects" problem without trying to control all access to the database ...like, say, Hibernate. I have a reasonably mature Hibernate app. It is almost exactly as easy to type createNativeQuery() as it is to type createQuery() . Many simple queries are shorter in JPQL, but for anything complex I always use SQL. I never feel like Hibernate is keepi…

But Hibernate will add extra complexity by it self. You can make mistakes in de mapping, then it adds multiple caches and you might use Spring and use the open-in-view filter... I am not stating that Hibernate (or JPA for that matter) is bad but it totally depends on what you are developing. Simple solutions can use Hibernate for more complex stuff you might not. Using JPA can also make your application independent from a specific database. But if you want to use advanced database features and have chosen a specific database you can not always use JPA.

Re: To ORM or Not to ORM

#254

Post by mpajunen »

spion wrote: post #208
derefr wrote: post #206

Earlier quoted context omitted.

So don't map DB records to objects, then. DB records are records , and their proper typing in your business logic is as records —chunks of plain old data, strongly-typed, that your (OO or otherwise) code can declare DB-side interfaces against. The only responsibilities of the module/class that owns the record type, should be getting things converted into and out of that record type. Plain-old-data DB record types (an…

Would that be a "RRM" (Record-Relational mapper)? If so we're already on board (in a different language). P.S. I bet you would never guess which typed language with great support for records makes it easy (for the most part) to build most type-safe SQL queries on the fly, even with projections, without explicitly defining types for every possible projection variation.

Any TypeScript libraries you are using?

Re: To ORM or Not to ORM

#255

Post by pjmlp »

Not to ORM.

Something like myBatis, jOOQ or Dapper are more than good enough for the boilerplate of building queries and data mapping.

No need to have needless generated SQL queries, with data going around the pipe, when it should be processed at the server side, taking advantage of the RDMS capabilities.

Re: To ORM or Not to ORM

#256

Post by philliphaydon »

merb wrote: post #184
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 "…

btw. even dapper writes that it only solves 95% of the problems: > Dapper's simplicity means that many feature that ORMs ship with are stripped out. It worries about the 95% scenario, and gives you the tools you need most of the time. It doesn't attempt to solve every problem. so basically stack overflow used a ORM for years. and i think they still use LINQ to SQL in coexistence with dapper.

I believe StackOverflow uses dapper for reads and EF Core for writes. Linq2Sql was used because EF was pretty horrible. But EF Core is pretty awesome.

Re: To ORM or Not to ORM

#257

Post by pjmlp »

stickfigure wrote: post #196
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 "…

Fortunately, there are tools out there that solve the "mapping tables to objects" problem without trying to control all access to the database ...like, say, Hibernate. I have a reasonably mature Hibernate app. It is almost exactly as easy to type createNativeQuery() as it is to type createQuery() . Many simple queries are shorter in JPQL, but for anything complex I always use SQL. I never feel like Hibernate is keepi…

Around 10 years ago, a work collegue improved the ETL processing time of a Java application from minutes to a couple of seconds, by dropping hibernate and using direct JDBC instead.

If all one is doing is calling createNativeQuery() all the time, and having stored procedures as well, then it is just needless fat.

Re: To ORM or Not to ORM

#258

Post by thoman23 »

spion wrote: post #208
derefr wrote: post #206

Earlier quoted context omitted.

So don't map DB records to objects, then. DB records are records , and their proper typing in your business logic is as records —chunks of plain old data, strongly-typed, that your (OO or otherwise) code can declare DB-side interfaces against. The only responsibilities of the module/class that owns the record type, should be getting things converted into and out of that record type. Plain-old-data DB record types (an…

Would that be a "RRM" (Record-Relational mapper)? If so we're already on board (in a different language). P.S. I bet you would never guess which typed language with great support for records makes it easy (for the most part) to build most type-safe SQL queries on the fly, even with projections, without explicitly defining types for every possible projection variation.

I get that you're talking about Typescript, but I just want to say that Scala excels in this area as well. I found Slick to be a pleasure to work with once I embraced not trying to map directly from a relational model to an object model, but instead to just use Scala's ability to manipulate and reshape the relational model as needed.

Re: To ORM or Not to ORM

#259

Post by campl3r »

out_of_protocol wrote: post #102

For everyone complaining about orm-something - take a look at elixir's Ecto. It basically allows writing sql via native code. Good for composability, type casting, stuff like that. Account |> where(active: true) |> join(:left, [a], p in Post, on: p.account_id == a.id) |> where([a, p], a.foo == "bar" or p.bar == "foo") |> group_by([a, p], a.id) |> select(...) |> limit(10) ... |> Repo.all() Plus there are changesets fo…

How is this different from Linq/EntityFramework for C#? Seems pretty similar at first.

Re: To ORM or Not to ORM

#260

Post by stickfigure »

pjmlp wrote: post #257
stickfigure wrote: post #196

Earlier quoted context omitted.

Fortunately, there are tools out there that solve the "mapping tables to objects" problem without trying to control all access to the database ...like, say, Hibernate. I have a reasonably mature Hibernate app. It is almost exactly as easy to type createNativeQuery() as it is to type createQuery() . Many simple queries are shorter in JPQL, but for anything complex I always use SQL. I never feel like Hibernate is keepi…

Around 10 years ago, a work collegue improved the ETL processing time of a Java application from minutes to a couple of seconds, by dropping hibernate and using direct JDBC instead. If all one is doing is calling createNativeQuery() all the time, and having stored procedures as well, then it is just needless fat.

If you have a trivial app that just executes a couple queries, then sure use JDBC?

I do not understand your point. Most business apps are not trivial.

Post reply on HN