Hi Russ
Ok - so I have a Git repository with Django trunk in it, and have
proceeded to change the commands. Following the changes there are no
failures in the regression tests. I am now trying to add new tests to
prove that my changes actually work.
Here is where I run into a few problems, no doubt at least in part as
I am new to this.
Q1. Should I create a separate, new module with my tests in it, or
just add tests to an existing module? If an existing one, how do I
determine which one?
Q2. In attempting my first test one change, it seems as though the
changes had had no effect. Have I missed some vital understanding...
I changed the last line of management/commands/flush.py thus
-print "Flush cancelled."
+self.stdout.write("Flush cancelled.\n")
and created a basic test thus:
def test_flush(self):
new_io = StringIO.StringIO()
management.call_command('flush', verbosity=0,
interactive=True)
command_output = new_io.getvalue().strip()
self.assertEqual(command_output, "Flush cancelled.")
I can see the test run, as it asks for a response. But it writes the
command output to stdout (i.e. in the shell window) and not to new_io.
This was copied from the example you suggested. Have I missed
something basic?
Regards
David
> > Longer term, if an administrative web interface to commands is to be
> > provided, we would need to devise an interface that adapted well into
> > the existing administrative interface. However, I see this as a second
> > stage in the process. First we need the command output to be
> > available.
>
> There may well be a place for these commands to be exposed via a web
> interface (especially if you're building a shared hosting type
> environment), but I'm not convinced that this is something that is
> appropriate to be baked into Django's core.
>
> Firstly, it's a bit of an edge case; the biggest use case for this
> sort of facility is to support a virtual server for which you don't
> have shell access. I don't have any firm numbers, but I suspect that
> this is an edge case of Django deployments.
>
> Secondly, some management commands aren't really well suited to
> execute on the same server that is serving them. It may be fine to
> have one server executing management commands on another, though
> (especially if you're setting up some sort of push-button hosting
> environment).
>
> Thirdly, some management commands can be time consuming or have the
> potential for introducing database locks; as such, they aren't well
> suited to execution in the request/response cycle. This means you
> should be looking at implementing this using a job queue, and Django
> is agnostic when it comes to such issues.
>
> That said, if such an administrative interface were to be introduced,
> it would almost certainly be as a contrib application. The usual path
> for adding new contrib applications is for them to start as a
> standalone project, and then be integrated when an argument can be
> made that they are a "defacto standard implementation of a common
> pattern". If this is something you're enthused about, I heartily
> encourage you to start it as a standalone project.
>
> Yours,
> Russ Magee %-)
--
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
