Re: Testing parameters in database settings

2014-03-05 Thread Shai Berger
Hi Josh, Thanks for your comments. The missing parameters are kinda a separate issue, with mush narrower audience. Yes, I'd like to have them in 1.7 too, and I doubt I'll have time to fix it myself -- so, PRs welcome. Cheers, Shai. On Wednesday 05 March 2014 14:07:02 Josh Smeaton wrot

Re: Testing parameters in database settings

2014-03-05 Thread Josh Smeaton
Mentioned on the PR already, but writing some thoughts here too. I like the change. Moving test settings into their own sub-dict makes a lot of sense. Missing are settings for creating the datafile and datafile size for Oracle though. I'm unsure if a separate patch should be submitted for those

Re: Testing parameters in database settings

2014-03-05 Thread Shai Berger
Hi, I've put up https://github.com/django/django/pull/2400 for review. It makes the changes discussed -- test settings go into a 'TEST' dictionary in the database settings, with a deprecation warning for old settings. While at it, I added (in a separate commit) a renaming of two Oracle-specific

Re: Testing parameters in database settings

2014-01-19 Thread Shai Berger
On Wednesday 15 January 2014 00:02:52 Michael Manfre wrote: > On Tue, Jan 14, 2014 at 3:26 PM, Shai Berger wrote: > > > > Your suggestion, if I understand it correctly, gives the user two options: > > > > 1) Use separate credentials, and perhaps even a separate service, for > > testing; > > this

Re: Testing parameters in database settings

2014-01-14 Thread Michael Manfre
On Tue, Jan 14, 2014 at 3:26 PM, Shai Berger wrote: > > The way testing currently works is by creating a throw-away database, > running > the tests on that, and throwing it away. This means, among other things, > that > you need settings for a database service and credentials for a user that > ca

Re: Testing parameters in database settings

2014-01-14 Thread Shai Berger
Hi, On Tuesday 14 January 2014 21:35:04 Michael Manfre wrote: > Why are we not encouraging people to define different aliases for testing? > Many of those TEST_ settings could be given meaning to the database > configuration without being specific to running tests. Several of those > TEST_ settin

Re: Testing parameters in database settings

2014-01-14 Thread Michael Manfre
I'm -0, on sweeping this explosion of settings (mostly for Oracle) under a "TEST" rug, instead of addressing the underlying problem. The entire TEST_* collection of settings is, in my opinion, a broken design that is used to shim a second "test" database configuration in a spot designed for a singl

Re: Testing parameters in database settings

2014-01-14 Thread Marc Tamlyn
+1, what Aymeric said. On 14 Jan 2014 17:50, "Aymeric Augustin" wrote: > This has bugged be for some time too. Fix it! > > Even if it's just for tests it would be nice to implement a simple > deprecation path. > > I'd simply call the new key TEST, but whoever writes the patch can choose > the nam

Re: Testing parameters in database settings

2014-01-14 Thread Aymeric Augustin
This has bugged be for some time too. Fix it! Even if it's just for tests it would be nice to implement a simple deprecation path. I'd simply call the new key TEST, but whoever writes the patch can choose the name :-) -- Aymeric. 2014/1/14 Shai Berger > Hi all, > > Django's database settin

Testing parameters in database settings

2014-01-14 Thread Shai Berger
Hi all, Django's database settings currently support eleven separate parameters for testing, all named 'TEST_*', most of them more-or-less backend-specific (in fact, six -- already a majority -- are Oracle-specific). We have now discovered[1] that we need even more Oracle-test-specific paramete