Earlier quoted context omitted.
> That's a pretty big advantage if you're an end-user who doesn't know how to create migrations. Such a migration should be created by drupal, not by the end-user in a proper design, you know, like everybody else does it. > The whole point is that you shouldn't be poking around in the DB most of the time (I will admit that this is a principle frequently violated). DB's tend to become the place to hook into other syst…
Sorry but you sound like you don't know what you're talking about. > I don't think drupal had any actual design goals You dont THINK? Well maybe you should LEARN and then you will KNOW. Actually Drupal is very good (the best framework I know) for migration and interoperating with other software. But you don't do that by connecting DBs directly like you seems to want to do... (which is wrong with any framework/cms)
I ran a drupal based business for years and I know the platform - and it's shortcomings - very well.
>> I don't think drupal had any actual design goals
> You dont THINK? Well maybe you should LEARN and then you will KNOW.
Well, I could have used stronger language there but I see no need. Because whatever I would have said you'd have found fault with the form rather than with the content. Believe me, I've spent enough time repairing and porting installations of drupal from one release to the next to know for a fact that their design goals are about as flexible as a rubber band and that they fail to deliver on the most basic ones (performance, ease of maintenance, backward compatibility and ease of upgrade).
> Actually Drupal is very good (the best framework I know) for migration and interoperating with other software.
Well, let's say our experiences probably are not identical.
> But you don't do that by connecting DBs directly like you seems to want to do... (which is wrong with any framework/cms)
For better or worse, DBs tend to be a relatively standard item and of course there is a 'right' way to do things (which is different for every platform), but having done several re-builds of large platforms we could probably agree on having a sane database schema and reasonable naming scheme to be a plus in such situations.
So from a pragmatic point of view this 'wrong' way is often the only way to achieve certain goals, and with drupal this way is nailed shut to the point that you are not only locked in to drupal, you are most likely going to end up being locked in to a specific drupal version (due to their modules usually not making it past an upgrade).
FWIW at some point in time I hosted thousands of drupal sites so I think (see, I'm doing it again, so feel free to take another cheap shot at me) that I have enough experience and familiarity with drupal to see it for what it is.