|
Wow, stack the deck much? If your application required connection to three databases concurrently, then you almost certainly wouldn't have chosen Django 1.0 as your application development platform. If connecting to multiple databases is a new requirement, then you're likely going to have to change much of your code / environment anyway, no matter whether or not you're using Django 1.0, 1.2, or Rails. Also, for what it's worth, the OP doesn't mention just Django, it mentions Pylons, Repoze, etc. Django isn't the only Python tool in the arsenal. Besides that, if you swap out your database abstraction layer in almost any language that I know of, you're going to have bigger problems than 'finding new plug-ins'. I can't think of a single ORM that is replaceable to another without significant retooling above the model layer. Most notably though, since you cite it as an example, losing the admin panel can hardly be considered as too big a deal, since the last time I looked at Rails, Symfony or Cake, none of them even offered that as a feature. As for your last sentence:
I'd rather use one tool that should cover my needs than be forced to switch them because they don't fit the needs of project. Can I safely assume that you're building everything in Java then? I mean, honestly, we pick the right tool for the job, don't we? We shouldn't be building things in Django because it's all we know, just as we shouldn't be building things in Ruby/Rails for that reason. Take a look at the challenges and figure out what makes sense. If you don't know wha the challenges are before you start developing (they're often surprising), then just start iterating until you figure out what they are. In this case, whatever framework or development platform lets you iterate the most quickly is the winner, whatever language it happens to be written in. |
"I'm curious why you think Django lacks quality and maturity." - This is what he wrote, so i gave him main reason why django is not the tool for me.
Which are perfectly valid in my opinion. And no - with sqlalchemys design, it DOES NOT require you to change your code if you just need to use few models with other databases - the change was about 20 lines of code in my case. Which i take would be not possible at all with django 1.0. You are right about "right tool for the job", for the kind of work I do, glue frameworks like pylons or bfg are a lot better choice - it's really way harder to corner me with some requirement that this stack can't handle.
And as for challenges, like I said - business conditions changed and I had to connect to 3 db's at once, no problems at all - if one chooses his tools very carefully in advance that can save a lot of headache later. Like I said, sorry for confusing you.
You can't predict everything that client could need/forgot to mention, so the more versatile your toolbox is the better.