Re: Feedback requested: One last time with multi-db

On Jan 23, 7:05 am, Russell Keith-Magee wrote: > A full explanation, including an example is in the documentation > portion of the patch, attached to ticket #12542. > > Comments? This fixed our only (known) blocking problem towards 1.2, thanks so much. Brett -- You

Re: Final call for feedback: Multi-db

On Jan 7, 7:33 pm, Russell Keith-Magee wrote: > then my understanding of your proposal is that the only change is that > read-slave won't get created under the test setup. But doesn't that > mean that:: > >     MyModel.objects.using('read-slave').filter(...) > > will fall

Re: Final call for feedback: Multi-db

On Jan 5, 8:09 pm, Russell Keith-Magee wrote: > If you're actually doing master/slave in the wild, your guidance may > actually be more enlightening than my theoretical navel gazing. In > particular - how have you got master/slave configured? How do you find > and select

Re: Final call for feedback: Multi-db

On Dec 22, 4:27 pm, Russell Keith-Magee wrote: >  * Allow TEST_NAME=None to mean "don't try and instantiate this > database in test mode" That sounds good, too. >  * Allow a top level TEST_DATABASES setting; TEST_DATABASES would > override DATABASES; if TEST_DATABASES

Re: Final call for feedback: Multi-db

On Dec 18, 9:50 am, Alex Gaynor wrote: > I'm wondering if perhaps the most prudent thing to do would be to > simply remove this check.  The end result will be you'll get an > integrity error on Postgres/Oracle when you try to save (and SQLite > and MySQL will just let you

Re: Final call for feedback: Multi-db

I'm not sure if 1.2 intended to fully support read-slaves, but I'll post this quick anyway as we've just run into it while trying to upgrade at DISQUS. You might think that having support for multiple databases implies that using a read-slave would Just Work, and that's mostly true. There's one

Re: I want a pony: Django Cheeseshop

On Wed, Sep 10, 2008 at 11:20 AM, mrts <[EMAIL PROTECTED]> wrote: > And it doesn't handle project-local installation (arguably this > can be done with virtualenv, but that will just clutter user-specific > "app-space" instead of the global one). At some point the Django app you're trying to

Re: New milestones for ticket triagers

On Sat, Sep 6, 2008 at 12:46 PM, daonb <[EMAIL PROTECTED]> wrote: > So we want a roadmap, to better help with ticket triage. You can reply > with -1 or 0 if you don't like the idea I very much doubt anyone is against a roadmap. Again, Djangocon _just_ started. Let me quote Jacob from this very

Re: New milestones for ticket triagers

On Sat, Sep 6, 2008 at 11:41 AM, daonb <[EMAIL PROTECTED]> wrote: > Jacob, please release a roadmap ASAP or let us know what version we > should use for new tickets. It's important to have a roadmap (and I'm > +1 for grasshoper's suggestion) Er, Django 1.0 was only released _3 days_ ago. You

Re: test coverage [was: web typography support]

On 8/6/07, Emanuele Pucciarelli <[EMAIL PROTECTED]> wrote: > There's Ned Batchelder's coverage.py: http://nedbatchelder.com/code/ > modules/coverage.html . Haven't tried it myself, but I have to > suppose that it's Django-friendly. :)

Re: Re[2]: usability issues

On 8/5/07, James Bennett <[EMAIL PROTECTED]> wrote: > Django handles both just fine, returns the same page for both. Not on our live site. And I just made a fresh django-trunk project to test it, didn't work there either. Although aren't resolvers just normal Python REs, so you could possibly