On Thu, Dec 9, 2010 at 11:45 AM, Russell Keith-Magee
wrote:
>
> During the original multi-db design process, we considered allowing
> for the definition of dependencies, but abandoned the idea because of
> the complexity required to get automated synchronization correct in
> every case. For exampl
On Thu, Dec 9, 2010 at 6:37 PM, Shai Berger wrote:
> Sorry I haven't kept up with this discussion; althugh the issue has now been
> closed, I'd like to say,
>
> On Sunday 05 December 2010 23:08:28 Nick Phillips wrote:
>> On Sat, 2010-12-04 at 11:56 +0800, Russell Keith-Magee wrote:
>> > Option 4:
Sorry I haven't kept up with this discussion; althugh the issue has now been
closed, I'd like to say,
On Sunday 05 December 2010 23:08:28 Nick Phillips wrote:
> On Sat, 2010-12-04 at 11:56 +0800, Russell Keith-Magee wrote:
> > Option 4: Introduce a per-database setting -- TEST_DEPENDENCIES --
>
Russell Keith-Magee ha scritto:
On Tue, Dec 7, 2010 at 11:21 PM, mpaolini wrote:
Maybe unrelated...
have you had a look at #14662?
It's related, but in the sense that it's the manual manifestation of
what #14799 needed to correct.
The contenttype and auth post_syncdb handlers ignore
On Tue, Dec 7, 2010 at 11:21 PM, mpaolini wrote:
> Maybe unrelated...
>
> have you had a look at #14662?
It's related, but in the sense that it's the manual manifestation of
what #14799 needed to correct.
The contenttype and auth post_syncdb handlers ignore --db by design --
they should be (and
Maybe unrelated...
have you had a look at #14662?
Marco
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-develop
On Sat, 2010-12-04 at 11:56 +0800, Russell Keith-Magee wrote:
> Option 4: Introduce a per-database setting -- TEST_DEPENDENCIES --
> that allows the developer to explicitly encode the dependency between
> databases. This means the developer can explicitly encode the
> dependencies that exists in d
My personal preference is for (4). I don't like the addition of a
setting, but it's a setting that most users will be able to ignore
(since there is a reasonably sensible default), and it is the most
explicit and configurable option available.
My opinion with the current codebase is for (4), b
#4 seems reasonable to me, with #3 as a runner-up. As you said: the
majority of users can ignore the new setting, which makes it far less
of a burden while still offering flexibility.
All the best,
- Gabriel
On Dec 3, 7:56 pm, Russell Keith-Magee
wrote:
> Hi all,
>
> I've been looking at #14
On Fri, Dec 3, 2010 at 10:56 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
> Hi all,
>
> I've been looking at #14799, and trying to work out the best approach
> for a solution. I can see three options, none of which are are
> particularly attractive. I'm looking for feedback on which o
Hi all,
I've been looking at #14799, and trying to work out the best approach
for a solution. I can see three options, none of which are are
particularly attractive. I'm looking for feedback on which one smells
the least.
First off - the problem:
* The test framework needs to create test databa
11 matches
Mail list logo
