On 01-Jun-06, at 12:32 PM, James Bennett wrote:
> > This would, probably, offer some benefit to novice developers, because > it's a couple less things they have to do at the outset (though it > arguably adds in some "magic" that it's better to have them > understand). But it offers zero benefit to experienced developers and, > most likely, would hinder them: they're going to want to develop on > something resembling their production environment, which means > probably MySQL or PostgreSQL (maybe even Oracle once the adapter for > it stabilizes sufficiently), and there's no guarantee that they'll > want to use the admin app -- there are plenty of uses for Django that > don't involve the admin at all. So this gets in their way and detracts > from the out-of-the-box usability of Django for its core audience. and as far as postgresql is concerned, i see a lot of use of triggers, rules, procedures etc which would be put in the db independantly of django. I also am already seeing bulk data entry, either script based or otherwise pulled from other sources, also directly to the database outside of django - so i agree, catering to group one should be the priority > > Thus, this proposal should probably be rejected. as far as trunk goes - no harm having it somewhere in contrib if it passes muster. But not a priority -- regards kg http://lawgon.livejournal.com http://avsap.org.in --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
