I'm using the multi-db branch actively on a large project.... I have found a few bugs, but am uncertain if they are specific to the branch or if are also found in the trunk, as I haven't ever installed the trunk.
I would like to try and take on maintenance of the branch...but am unsure of how to get started with that ( if anyone can give me some information on how to get a subversion account, and how to get started etc. feel free to tell me. ). There weren't any notes as to the specific merging issues, and JP said it takes 4 hours to merge conflicts each time the trunk is merged with the branch. If a core developer would be willling to help me through the first merge with the trunk... I'd like to get it back to being an active branch. On May 1, 8:21 pm, Brian Luft <[EMAIL PROTECTED]> wrote: > Although I've successfully used the multi-db branch experimentally, it > looks to be getting more and more out of date with the django trunk. > I do completely understand the desire of the django devs to ensure a > solid commitment to a branch and also that there have not been enough > requests to drive inclusion by default into the main development > line. That said, let me throw my single vote for support of this > feature. I'm a little surprised that more people apparently aren't > using Django against legacy databases which in my mind usually > presents a strong case for the need to be able to split data across > different databases or least schemas in cases such as Postgres. Also, > I've seen a number of other people mention in the archives that they > employ separation strategies based on varying requirements for their > applications. > > Just for the sake of lively discussion, I would go so far as to say > that only being able to access a single database per project is an > unfortunate limitation and could be a deal-breaker for those > evaluating Django for their own use. I'm sure there are many > arguments for why the 'global' database settings reduce code > complexity and provide optimizations. Being mostly ignorant about the > inner workings of Django, it seems like it would be possible to allow > at least per app specification overrides by simply dropping another > settings file into an app. > > Of course, as they say, the beauty of open source / open community is > that you can just go build it yourself. In a fantasy world I would be > all about that but in reality I can't keep up with my own personal > projects and I've "involved" myself in other projects when I really > couldn't make the long term commitment. So here's to hoping that my > pitiful plea plants the tiniest of seeds in the brilliant django dev > minds and here's to hoping that more in the community share my > viewpoint and make themselves heard. > > Thanks for listening. > > Cheers > -Brian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
