This problem was logged as a bug and closed without fixing because the
development team thought it was not worthwhile.
See Jacob K-M's comment at the bottom for an explanation why.
http://code.djangoproject.com/ticket/8906
On Jun 3, 10:30 pm, "eric.frederich" wrote:
> So the person in IT that r
You will need to adjust the LOGIN_URL (and possibly
LOGIN_REDIRECT_URL) setting in your settings file. One way to do this
would be to add a separate settings file for production if you don't
already have one. The production settings file can then have the
appropriate value for LOGIN_URL, say somet
I am using python's logging module in a django project. I am
performing the basic logging configuration in my settings.py file.
Something like this:
import logging
import logging.handlers
logger = logging.getLogger('project_logger')
logger.setLevel(logging.INFO)
LOG_FILENAME = '/path/to/log/file
I have created an initial_data fixture for using with my test cases.
However I do not want these to be loaded every time I run syncdb after
making a change during development. Is there a way to turn off loading
initial_data, perhaps using a command line switch?
Thanks,
Manoj
--~--~-~--~
s I should rephrase my question thus:
How can I load static, one-time-load data for use with test cases
without using either Django's TestCase or initial_data?
Many Thanks,
Manoj
On Jul 17, 11:15 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On 7/17/07, Manoj
data.
Regards,
Manoj
On Jul 17, 11:15 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On 7/17/07, Manoj Govindan <[EMAIL PROTECTED]> wrote:
>
>
>
> > I have created an initial_data fixture for using with my test cases.
> > However I do not wa
> IMHO, this is a dangerous statement to make - what if one test makes
> an (mistaken) change in the database? Then all your subsequent tests
[snip]
My application does *not* make any inserts/updates to the database. It
merely selects and presents data based on user inputs (application is
up here
> If there are times that you don't want to load the data, then it isn't
> initial data. Put it in a different fixture, and load it when you need
> it.
>
I am bit confused now. Are you implying that the developer should not
prepare an initial_data fixture (with data that is absolutely
essential f
> You think. For the moment. Until one day, something subtle changes in
> the implementation of get_foobar() which _does_ change data, and the
> change is made by someone that didn't get the memo from 2 years ago
> that said that the app must not change data, etc ...
1) I am the sole developer
2)
> This is because Django's test case flushes the database between each
> test. This is the right thing to do for testing purposes, because it
> removes the possibility of crossover effects in the testing process,
> but it does impose a slowdown (because flushing is an expensive
> operation).
>
I
>
> Is this comparison something you have done personally? If so, can you
Yes. I wrote the same application in Rails before I moved to Django (I
have always liked Python ;))
While the tests themselves are not *identical* there were about the
same number of them.
> provide any benchmarking detail
Recently I tried using Sqlite instead of Postgres as the database
engine for testing one of my django applications.
My observations follow:
1) Tests ran significantly faster[1].
2) Some tests failed in Windows while some of them failed in both
Windows and Linux. All tests succeeded in both operat
Hi Jacob,
>
> Under Sqlite tests run in an in-memory database, so this is perfectly
> normal. Like you, I see about a 10x speedup running tests against
> Sqlite.
>
Not surprisingly the tests slowed down once I added the
TEST_DATABASE_NAME parameter to settings. It made debugging easier
though.
Is there a way to check out the latest version of Django code using
the svn+ssh mechanism?
svn co svn+ssh://code.djangoproject.com/svn/django/trunk/django
I am obliged to do this as the proxy server I rely on (but do not
control) is not configured to recognise the necessary HTTP methods
such as R
I routinely write views which use two built-in decorators, viz.,
login_required and transaction.commit_on_success. I am able to easily
write test cases for the former. A typical test case looks like this:
self.client.logout()
response = self.client.get(reverse('my_view'))
redirect_url =
self.a
Hi,
Consider a model and a simple test for the model.
class Project(models.Model):
name = models.CharField(maxlength = 255)
parent = models.ForeignKey('self', null = True)
class ProjectTests(unittest.TestCase):
def testCreateProjectAndSubProject(self):
project = Project(name
if one (or more) of the developers could please
have a look at this and tell me if and where I am going wrong.
Thanks,
Manoj
On Feb 25, 9:18 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sat, 2007-02-24 at 18:41 +, Manoj Govindan wrote:
> > Hi,
> > Conside
Will 0.96 have support for fixtures (a la #2333)?
Also, am I the only one waiting for them? ;)
Regards,
Manoj
On Feb 26, 9:56 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> Upcoming Django release, and the future
>
> As we sit here in warm, sunny Dallas, meditating on how next year's
> PyCon w
> The serializer in trunk has a fields option, which only serializes the
> fields supplied.
>
> Ex:
> serializers.serialize('json', my_user_set, fields=('username', 'id'))
This doesn't work at the moment
http://code.djangoproject.com/ticket/3466
But luckily there is also a patch ;)
Regards,
M
Hi Malcolm,
> I would like to see if subProject.parent the first time you test it
> (your first assert()) is exactly the same as after the subProject.save()
> line.
>
I did a bit of debugging and uncovered the following facts. I think
they explain the goings on pretty clearly.
Let us take the s
Hi Bram,
Here is a possible mechanism to address your second point, i.e., hide
certain fields while serializing.
Consider this model:
class Person(models.Model):
... # various fields here.
@staticmethod
def fields_for_serializing():
return [list of those field names that can
> Testing is a must have for long term support. Templatetags are great too.
>
I second this. You might want to include the newly introduced support
for Fixtures (XML, JSON, Python and YAML).
Regards,
Manoj
--~--~-~--~~~---~--~~
You received this message because
How many here follow the django axiom of 'one project, multiple apps'?
If you do, how do you control the sources? Do you map one project to
one source code repository or do individual apps get their own
repositories?
--~--~-~--~~~---~--~~
You received this message
On Oct 17, 12:30 pm, Margaret <[EMAIL PROTECTED]> wrote:
> version control system???
> or local filesystem??
>
Version control system, say SVN.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
One of my applications has a view that uses a random number generator.
I am having some trouble passing a mock random generator to the view
for testing purposes.
I am relying on the mock object to get predictable results for testing
the view's logic.
After several attempts I came up with an URL t
> Django demonstrates at least one example of an alternative in its own
> test framework, through the way that email is handled during testing.
>
Perfect!
Thanks,
Manoj
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Gr
My application has a view that accepts a string parameter and filters
a model based on that parameter. In the development environment the
view works well when passed a string with a space in it, say 'hello
world'. The portion of the url representing the parameter shows up as
'hello%20world'.
I th
>
> Note I am using 0.96, the production distro.
The ability to iterate through dictionaries is only available in the
*development* version.
Documentation URL:
http://www.djangoproject.com/documentation/templates/#for
>From the django site:
This can also be useful if you need to access the item
On Nov 18, 12:00 pm, "Ramdas S" <[EMAIL PROTECTED]> wrote:
> are u using windows?
>
I am working on Ubuntu Feisty.
Are you suggesting that the behaviour is different on Windows?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Goog
>
> I am still not clear about your question. But my guess is that this is
> an accepted behaviour. Spaces are read as %20 on URLs.
> If you can cut paste the exact sample code on dpaste, some one can
> help you
>
I am aware that spaces are represented as %20 on URLs.
My observations were
1) Du
I have raised a ticket for this problem.
http://code.djangoproject.com/ticket/5982
I have added the relevant code snippets there.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this
Hi,
I have written a small test making use of test.Client to simulate a
'POST' request to a view. The target view is expected to set a certain
variable in the session on successful handling of the request. Can
anyone suggest a suitable mechanism to check in the test if the
session variable has bee
On Feb 9, 11:49 am, Margaret <[EMAIL PROTECTED]> wrote:
> would you like paste your code of "test"?
>
> On 2/9/07, Manoj Govindan <[EMAIL PROTECTED]> wrote:
>
>
>
> > Hi,
> > I have written a small test making use of test.Client to sim
Hi Russ,
Thanks for your prompt reply.
I tested the solution you suggested and came up with some questions.
Here they are.
> session =
> SessionWrapper(self.cookies.get(settings.SESSION_COOKIE_NAME, None))
> self.assertTrue(session['key'], value)
>
First of all, I could not find
Addendum:
I tried the following and it did return a session.
session = SessionWrapper( self.client.cookie.get( 'id' ) )
However this session does not have _any_ keys. I am presently checking
my code ...
>
> Say something like this.
>
> session = SessionWrapper( self.client.cookie )
>
--~--~-
Apologies for the flurry of messages.
I just wanted to note that this worked:
session =
SessionWrapper( self.client.cookie.get( 'sessionid' ).value )
The above fragment returned me the session from the db that I was
looking for.
I am still confused. Russell, can I persuade you to explain what i
> the session information from the database, and you query the wrapper
> for individual session data.
>
> Does this help explain the process?
>
It certainly does.
Thanks!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Gr
37 matches
Mail list logo
