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

241–250 of 300 posts

Re: To ORM or Not to ORM

#241

Post by rhlsthrm »

karmakaze wrote: post #209
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'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.

Re: To ORM or Not to ORM

#242

Post by gigatexal »

collyw wrote: post #188
gigatexal wrote: post #116

Go with an ORM when your schema is still in flux but transition to raw SQL when you can the tech debt and performance overhead is just insane otherwise.

Only if you don't know how to use your ORM properly.

Perhaps there are performant ORMs but in my experience ones like SQLAlchemy are terribly slow in that they make it very easy to have not so optimized queries.

I’d wager though that hand crafted queries tuned with the right indexes and the like are going to be much quicker than any abstraction like an ORM. If you’re using it as just a query builder then that’s something else.

Re: To ORM or Not to ORM

#243

Post by drwiggly »

SOLAR_FIELDS wrote: post #201
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…

Lack of adequate support for versioning your schema and in general bad support for anything versioning with RDBMS is one of the main dislikes I have for SQL. I find SQL to be a beautifully expressive language when you get the hang of it, but no RDBMS that I know of has been able to adequately tackle the versioning problem at both the schema and the script level. Everyone's schema evolves over time, why is it so diffi…

Yes I agree. I ended up making a small DSL to describe tables. Then another program to translate that in to a script that checks everything through meta data in the target db (atm it does mysql). I check the table structure files into version control. If I wanted an old version pull that checkout and run the generator script. I end up with a pure SQL script that creates a blank db with bootstrap data or asserts all the columns/indexes exist for that version of the code.

There is another small dsl for bootstrap data, and I just check in all stored procs like normal code.

What this doesn't give you is good change column type semantics but any other tool I've ever used when this happens, can't be trusted anyway you have manage it yourself. This type of change is pretty infrequent though.

For me it works better to assert the schema I want now. Drop columns arn't done due to similar thorny issues that usually a human has to deal with. Or if its simple I put those in a cleanup proc that runs as the last part of the script.

Using normal code to describe structure I guess is similar its just you're fighting the language with meta data extensions, and also whatever you do isn't language agnostic. You're also at the mercy of whatever magic is going to happen when you change schema with that lib.

Re: To ORM or Not to ORM

#244

Post by lowbloodsugar »

The ORM discussion is really just a proxy for "Have you had lots of experience managing data in production" (in which case against ORM), and also "Have you had lots of experience managing data with a team of green engineers" (who most all want to use ORM because it's cool, but also, hell no).

Now, about the only way for a developer to understand how awful they are is to really spend some time going all out with them. So my advice would be to embrace ORMs whole heartedly, as soon in your career as possible. As you debug it, you'll learn lots of wonderful things.

Re: To ORM or Not to ORM

#245

Post by pezo1919 »

My favourite orm is Peewee for python.

I really like how clean it is.

grandma = Person.get(Person.name == 'Grandma L.')

or

query = Pet.select().where(Pet.animal_type == 'cat')

for pet in query:

  print(pet.name, pet.owner.name)
I am looking for something similar for javascript and lately for Typescript, but I could not find anything with similar readibility and logic.

Do you have any idea?

http://docs.peewee-orm.com/en/latest/peewee/quickstart.html#...

Re: To ORM or Not to ORM

#246

Post by MartinCron »

nullwasamistake wrote: post #227
krisrm wrote: post #169

Earlier quoted context omitted.

I'm still at the "hating it" stage, but most of my Hibernate experience has been with older versions of Java (5 & 6), or with trying to deal with other people's HQL sprinkled all over. It's a lot of rope to hang one's self with, IMO. Not that native SQL isn't, but there's something to be said for an enforced separation of concerns that I feel like Hibernate breaks a little too often.

My most useful suggestions to less hate: Turn on the MetaModel code generation stuff. Use Criteria with strongly typed queries for everything that's not a simple find. Much less potential mistakes in combination with validation. Always turn on HBM2DDL validation! Without this you won't know if there's a problem between entity->table mappings until a query explodes. For the same reason, don't use HQL or Raw DB queries…

If I had a time machine, I would send this comment back to myself a few years ago. Would have saved me a lot of pain from “winging it”.

Thanks for sharing

Re: To ORM or Not to ORM

#247

Post by victor106 »

From the creator of Hibernate Gavin King

"Just because you're using Hibernate, doesn't mean you have to use it for everything.”

https://mobile.twitter.com/javaooq/status/504184043765002240

This is how I use it 1. Use Hibernate for most updates. 2. Use JOOQ for reads. Gives you everything from compiler checks to type safety.

ORM is a tool. Just like any other tool in CS or non-CS you have to know when to use it and when not to use it and what other options exist.

Re: To ORM or Not to ORM

#248

Post by ketzo »

pezo1919 wrote: post #245

My favourite orm is Peewee for python. I really like how clean it is. grandma = Person.get(Person.name == 'Grandma L.') or query = Pet.select().where(Pet.animal_type == 'cat') for pet in query: print(pet.name, pet.owner.name) I am looking for something similar for javascript and lately for Typescript, but I could not find anything with similar readibility and logic. Do you have any idea? http://docs.peewee-orm.com/en…

I really like Sequelize after using it in a couple of small projects. Not quite that level of concise, but I find it to be a really nice balance of concision and flexibility.

Person.findOne({where: {name: "Grandma L."}})

Person.findAll({where: {age: 30}})

Particularly, I really like how associations are handled. If I have a one-to-many association between Posts and Comments, I can do something like this:

Post.findOne({where: {title: "My Article}})

  .then( article => {

    article.getComments()

      .then( comments => {

      // do something with all comments of Post "My Article"

      });

  });
http://docs.sequelizejs.com/manual/

Re: To ORM or Not to ORM

#249

Post by mceachen »

kasey_junk wrote: post #2

One thing I really miss from the JVM world was something like jOOQ. I don't want an ORM (like specifically the object relational mapping stuff) for most of my use cases but I do want an abstraction above text for interacting with SQL. gorm's sql builder is alright but something better would be really nice.

If you're using node, try https://knexjs.org/. The API is very similar.

Re: To ORM or Not to ORM

#250

Post by coleifer »

pezo1919 wrote: post #245

My favourite orm is Peewee for python. I really like how clean it is. grandma = Person.get(Person.name == 'Grandma L.') or query = Pet.select().where(Pet.animal_type == 'cat') for pet in query: print(pet.name, pet.owner.name) I am looking for something similar for javascript and lately for Typescript, but I could not find anything with similar readibility and logic. Do you have any idea? http://docs.peewee-orm.com/en…

Ha! Glad to see Peewee mentioned. In two bullet points: predictable apis, compostable pieces...or, learn once, apply anywhere. Or jOOQ but python. Take your pick!

If code is your thing, Peewee has quite a few examples:

https://github.com/coleifer/peewee/tree/master/examples

Post reply on HN