3 ms·

> If you don't want to learn an immensely popular and widely used library that's in pretty high demand career-wise, well, that's your lookout You’re making the

> If you don't want to learn an immensely popular and widely used library that's in pretty high demand career-wise, well, that's your lookout You’re making the argument against yourself. Even including different dialects an in depth knowledge of SQL is far more valuable than knowledge of Hibernate. Over a decade ago now I used NHibernate, the .NET version of Hibernate on a project. Since that project I’ve written code in JavaScript (Node), Python, Rust, played around with a little Go and Kotlin. In all those years the only database engine I’ve used seriously is Postgres. Knowledge of Postgres has been invaluable throughout my career. I can’t remember anything about NHibernate. It’s not even specific to NHibernate either, I had to use ORMs in other situations (like Sequelize on Node) and I haven’t retained any of that either.

lmm 3y ago
> Over a decade ago now I used NHibernate, the .NET version of Hibernate on a project. Since that project I’ve written code in JavaScript (Node), Python, Rust, played around with a little Go and Kotlin. > In all those years the only database engine I’ve used seriously is Postgres. Interesting, I would think changing database happens a lot more than changing language for most developers. Over the last decade I've worked on systems that used MySQL, Postgres, Oracle, H2, and Sybase, but they've all been on the JVM and almost all used Hibernate (one used EclipseLink but a lot of the knowledge transferred over - even if something isn't called exactly the same thing, they have the same kind of capability structured in a similar way - much smaller than the differences between databases IME. Indeed even having to use e.g. Django ORM occasionally a lot of stuff transferred over). Spending time learning to use an ORM well was absolutely a good investment, far more useful than a bunch of SQL details would've been. Like, if a company has a Ruby/MySQL stack, they're going to hire someone whose experience was Ruby/Postgres over someone whose experience was Python/MySQL. So if you're a Ruby dev then you open more doors for yourself by learning Ruby's standard ORM in depth than you do by learning a specific database in depth. > I can’t remember anything about NHibernate. It’s not even specific to NHibernate either, I had to use ORMs in other situations (like Sequelize on Node) and I haven’t retained any of that either. I suspect that reflects more on what you paid attention to and were interested in using rather than anything fundamental about how easy or hard ORMs are to learn.
- afavour 3y ago
  > a lot of the knowledge transferred over - even if something isn't called exactly the same thing, they have the same kind of capability structured in a similar way At a certain point this is getting beyond parody. That statement sounds exactly like it’s discussing SQL! > I suspect that reflects more on what you paid attention to and were interested in using rather than anything fundamental about how easy or hard ORMs are to learn. Nor am I saying anything about anything being easy or difficult to learn. I’m talking about what’s transferable. In my experience ORMs are far less transferrable than SQL knowledge. I think it’s safe to say we’re going to have to agree to disagree here.
  - lmm 3y ago
    > At a certain point this is getting beyond parody. That statement sounds exactly like it’s discussing SQL! Nope. The underlying relational model is great. Knowing what tables are like, how and why indexes work (and when they don't), transaction isolation levels, all that stuff is extremely useful transferrable knowledge (and will help you out whether you're using an ORM or not). Knowing the three or four different bizarre pseudo-COBOL variants that different database vendors use to express something like "pull rows recursively from this table" or "format this string using these two numbers and this date" is stamp collecting at best.
    - tannhaeuser 3y ago
      Disagree. All too often, JPA/Hibernate dumbs the relational model down into record-at-a-time processing with navigational queries reminiscent of pre-relational network databases and counting and joins implemented by unnecessary fetching and client-side processing rather than aggregate queries and joins. Furthermore, it brings fuzzy locking semantics/locking as a side effect of lazy/eager fetching and artifacts such as a pattern of unnecessary "id" columns due to lack of support or asymmetrical and idiosyncratic handling of compound keys, also extra magic for "many-to-many connectives" (the wording alone is non-relational), lack of attention for decimal arithmetic/overflow with money values, idiosyncratic date/time conversions and mappings of enums into ordinals, etc. etc.
kaba0 3y ago
By that logic learning .NET, Python, etc was all invaluable as you are no longer using them, right?
keithnz 3y ago
what's there to remember? NHibernate you basically use Linq, so if you remember Linq you remember NHbernate. The only extra bits are the setup and mappers, which are sort of trivial. The pain points come around because NHhibernate decides to lazy load everything or ends up doing crazy joins. But overall I found NHibernate not too bad, it certainly was fast doing a lot of basic CRUD type stuff. However, these days I use Dapper.NET and SQL. Dapper gives a nice mapper for parameterized queries and maps results to types. I think it's a nice middle ground.
fragmede 3y ago
> I can’t remember anything about NHibernate. I'd argue that means it's doing its job quite successfully! The point of using an ORM is so you don't have to also be a DBA on top of writing code. If I have to remember a bunch of implementation details and program weirdly because of the leaky abstraction that is an ORM, then the ORM has failed. If I grab all the rows from the database and then WHERE clause them in my code, instead of querying the database with a WHERE clause, and then wonder when my program's slow, that's on me. But if the ORM makes it straight forwards not to, so I don't need to grok the database, so I can focus on the other problems, then I'd consider it a success.

lmm 3y ago

> Over a decade ago now I used NHibernate, the .NET version of Hibernate on a project. Since that project I’ve written code in JavaScript (Node), Python, Rust, played around with a little Go and Kotlin. > In all those years the only database engine I’ve used seriously is Postgres. Interesting, I would think changing database happens a lot more than changing language for most developers. Over the last decade I've worked on systems that used MySQL, Postgres, Oracle, H2, and Sybase, but they've all been on the JVM and almost all used Hibernate (one used EclipseLink but a lot of the knowledge transferred over - even if something isn't called exactly the same thing, they have the same kind of capability structured in a similar way - much smaller than the differences between databases IME. Indeed even having to use e.g. Django ORM occasionally a lot of stuff transferred over). Spending time learning to use an ORM well was absolutely a good investment, far more useful than a bunch of SQL details would've been. Like, if a company has a Ruby/MySQL stack, they're going to hire someone whose experience was Ruby/Postgres over someone whose experience was Python/MySQL. So if you're a Ruby dev then you open more doors for yourself by learning Ruby's standard ORM in depth than you do by learning a specific database in depth. > I can’t remember anything about NHibernate. It’s not even specific to NHibernate either, I had to use ORMs in other situations (like Sequelize on Node) and I haven’t retained any of that either. I suspect that reflects more on what you paid attention to and were interested in using rather than anything fundamental about how easy or hard ORMs are to learn.

afavour 3y ago
> a lot of the knowledge transferred over - even if something isn't called exactly the same thing, they have the same kind of capability structured in a similar way At a certain point this is getting beyond parody. That statement sounds exactly like it’s discussing SQL! > I suspect that reflects more on what you paid attention to and were interested in using rather than anything fundamental about how easy or hard ORMs are to learn. Nor am I saying anything about anything being easy or difficult to learn. I’m talking about what’s transferable. In my experience ORMs are far less transferrable than SQL knowledge. I think it’s safe to say we’re going to have to agree to disagree here.
- lmm 3y ago
  > At a certain point this is getting beyond parody. That statement sounds exactly like it’s discussing SQL! Nope. The underlying relational model is great. Knowing what tables are like, how and why indexes work (and when they don't), transaction isolation levels, all that stuff is extremely useful transferrable knowledge (and will help you out whether you're using an ORM or not). Knowing the three or four different bizarre pseudo-COBOL variants that different database vendors use to express something like "pull rows recursively from this table" or "format this string using these two numbers and this date" is stamp collecting at best.
  - tannhaeuser 3y ago
    Disagree. All too often, JPA/Hibernate dumbs the relational model down into record-at-a-time processing with navigational queries reminiscent of pre-relational network databases and counting and joins implemented by unnecessary fetching and client-side processing rather than aggregate queries and joins. Furthermore, it brings fuzzy locking semantics/locking as a side effect of lazy/eager fetching and artifacts such as a pattern of unnecessary "id" columns due to lack of support or asymmetrical and idiosyncratic handling of compound keys, also extra magic for "many-to-many connectives" (the wording alone is non-relational), lack of attention for decimal arithmetic/overflow with money values, idiosyncratic date/time conversions and mappings of enums into ordinals, etc. etc.

kaba0 3y ago

By that logic learning .NET, Python, etc was all invaluable as you are no longer using them, right?

keithnz 3y ago

what's there to remember? NHibernate you basically use Linq, so if you remember Linq you remember NHbernate. The only extra bits are the setup and mappers, which are sort of trivial. The pain points come around because NHhibernate decides to lazy load everything or ends up doing crazy joins. But overall I found NHibernate not too bad, it certainly was fast doing a lot of basic CRUD type stuff. However, these days I use Dapper.NET and SQL. Dapper gives a nice mapper for parameterized queries and maps results to types. I think it's a nice middle ground.

fragmede 3y ago

> I can’t remember anything about NHibernate. I'd argue that means it's doing its job quite successfully! The point of using an ORM is so you don't have to also be a DBA on top of writing code. If I have to remember a bunch of implementation details and program weirdly because of the leaky abstraction that is an ORM, then the ORM has failed. If I grab all the rows from the database and then WHERE clause them in my code, instead of querying the database with a WHERE clause, and then wonder when my program's slow, that's on me. But if the ORM makes it straight forwards not to, so I don't need to grok the database, so I can focus on the other problems, then I'd consider it a success.