It is the same as with all frameworks: it promises productivity and speed of development, but in exchange for that the problem that you are trying to solve must fit within the model and the assumptions that were made by authors of the framework. In the end, that is never really the case and depending on the situation, fixing the last 20% of your work takes less/all/more of the amount of time that you saved. So sometimes a framework is a good choice, but is never as easy as the tutorial makes it seem.
ORM's are a bad case of this, because they try to bridge the impedance mismatch between how data is stored and linked in the database and the programming language you are using. This creates a forced model and a whole lot of assumptions and in the end it is still not good enough. Fixing the part of your project that does not fit the ORM's assumptions gets magnitudes harder because the bridge they built is very complex.
Yes, most ORM's allow you to write direct SQL queries, but that does not really solve the problem. You work the way it was intended, or you do not not. If the latter is the case, you will encounter difficulties, no matter the way break the 'rules'.
ORM's are a bad case of this, because they try to bridge the impedance mismatch between how data is stored and linked in the database and the programming language you are using. This creates a forced model and a whole lot of assumptions and in the end it is still not good enough. Fixing the part of your project that does not fit the ORM's assumptions gets magnitudes harder because the bridge they built is very complex.
Yes, most ORM's allow you to write direct SQL queries, but that does not really solve the problem. You work the way it was intended, or you do not not. If the latter is the case, you will encounter difficulties, no matter the way break the 'rules'.