Re: Document direct API usage of FileField and ImageField

[Owen Nelson]

Actually, I'm not sure what way to go with this.  All the info is there,
it's just spread around in a number of topics:

http://docs.djangoproject.com/en/dev/ref/files/file/

http://docs.djangoproject.com/en/dev/topics/http/file-uploads/

http://docs.djangoproject.com/en/dev/topics/files/

http://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.FileField

I'd almost say the best way to explore file handling would be to add an
"extra credit" tutorial -- an extension of the poll app that serves as
django's HelloWorld.  Tricky thing is that there are a lot of moving
parts... the storage system, upload_to, serving static files (if using
./manage.py runserver), upload handlers, the concepts around the File
wrapper...  It's all a bit much for a newcomer to the project.


On Fri, Sep 17, 2010 at 2:11 PM, Owen Nelson  wrote:

> I'd love to pitch in on updating the docs for file handling :)
>
>

-- 
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.

Re: Document direct API usage of FileField and ImageField

[Owen Nelson]

I'd love to pitch in on updating the docs for file handling :)

Even though this kind of talk is better suited over on django-users,  here's
one way to skin a cat.
I had a view that displayed a model form (one of the fields was a
FileField).  I needed to alter the resolution of the uploaded image to make
sure it wasn't HUGE.

http://dpaste.org/oN2J/

In my case, I was resizing the original image *after* it had been stored
according to the file field's upload_to settings.
The 'image' I got from the form is basically a file object (
http://docs.djangoproject.com/en/dev/ref/files/file/) which is what I
tripped up on at first when putting this together.  You have to make sure
whatever you pass to ImageField as "contents" is an object that implements
that "File" interface, so to speak.  In the case of the upload from the
form, this was done for us, but if you have some random file on the
filesystem, you'd do something like this:

from django.core.files import File

tmpfile = File(open('/tmp/some-pic.jpg','rb'))
object.image.save('pic.jpg', tmpfile, save=True) # copy the image to
it's proper location and save the model instance when done.

-- 
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.

Proposal: Add signals test_setup and test_teardown to Django test suite runner

[Jim D.]

I recently asked a question on Django Users related to executing
certain code during the global setup and teardown routines that run in
Django's test runner. In my particular use case, I was looking for a
hook where I could disable some third party API code when tests
execute, in much the same way that Django itself swaps out the email
backend during testing to ensure no emails are actually sent.

Anyhow, it seems the only solution at the time being is set up a
custom test runner, which is what I ended up doing. However, it
occurred to me that a more elegant approach would be to use signals
that run during setup and teardown, which applications could hook into
if they needed to do any global setup or teardown actions. To me, this
seems like an excellent solution to the problem (it's actually what I
implemented in my custom test runner I ended up using).

I wonder if this is something that would be considered for addition to
the core? I at least wanted to throw it out there for discussions.

I've included a patch I wrote to implement this in the core test
module, at the bottom of this message. It should be mostly self
explanatory. Note that the call to send the test_setup figure has to
occur after get_apps() has executed in build_suite(), since
applications aren't loaded until then and any signal connections would
not yet have had a chance to be set up.

Just a few arguments to throw out in favor of this idea:

* Requiring a custom test runner to implement this behavior makes it
(nearly) impossible for reusable applications to modify global setup
and teardown behavior, since it would become the responsibility of the
project itself to specify the custom test runner.
* The current setup gives the Django core "privileged" access to
disable certain features during testing, it would seem that
application should be given the capability as well.
* Signals are non obtrusive...if they are not used they don't really
harm anything.
* None of the proposed changes would impact production code, since
they are all restricted to the test suite. In fact the patch is really
only about 5 lines of additional code.

Anyhow, hopefully this is something you guys would be interested in
considering. Apologies if this topic has been discussed or proposed
before, but in searching I could not find anything related to it.

Proposed patch:


Index: test/simple.py
===
--- test/simple.py  (revision 13861)
+++ test/simple.py  (working copy)
@@ -7,6 +7,7 @@
 from django.test import _doctest as doctest
 from django.test.utils import setup_test_environment,
teardown_test_environment
 from django.test.testcases import OutputChecker, DocTestRunner,
TestCase
+from django.test.signals import test_setup, test_teardown

 # The module name for tests outside models.py
 TEST_MODULE = 'tests'
@@ -246,7 +247,11 @@
 else:
 for app in get_apps():
 suite.addTest(build_suite(app))
-
+
+# This signal can't come any earlier, because applications
are actually loaded
+# in get_apps()
+test_setup.send(sender=self)
+
 if extra_tests:
 for test in extra_tests:
 suite.addTest(test)
@@ -284,6 +289,7 @@
 connection.creation.destroy_test_db(old_name,
self.verbosity)

 def teardown_test_environment(self, **kwargs):
+test_teardown.send(sender=self)
 teardown_test_environment()

 def suite_result(self, suite, result, **kwargs):
Index: test/signals.py
===
--- test/signals.py (revision 13861)
+++ test/signals.py (working copy)
@@ -1,3 +1,6 @@
 from django.dispatch import Signal

 template_rendered = Signal(providing_args=["template", "context"])
+test_setup = Signal()
+test_teardown = Signal()
+

-- 
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.

Re: making queryset.delete issue only a single SQL query

[Tobias McNulty]

On Fri, Sep 17, 2010 at 8:27 AM, SmileyChris  wrote:
>
>  On Sep 11, 1:12 pm, Tobias McNulty  wrote:
> > I may be missing something, but queryset.delete() seems oddly implemented
> in
> > Django.  It does a select to get all the IDs to be deleted, and then
> deletes
> > them, in blocks of 100 I believe, by ID.
>
> It's because .delete() is emulating the behavior of the SQL constraint
> ON DELETE CASCADE
>
> A list of objects to be deleted is recursively populated, then this
> complete list of objects is iteratively deleted (also calling the
> pre_delete and post_delete signals in their respective places).


Hm, I see that now, and I suppose there's no sense in changing that
behavior.

To my credit, the docs are a little misleading, specifically the line
reading "Keep in mind that this will, whenever possible, be executed purely
in SQL, and so the delete() methods of individual object instances will not
necessarily be called during the process." [1]  Additionally, is ambiguous
whether the part about "ON DELETE CASCADE" applies just to single objection
deletion or to queryset deletion as well.  Admittedly what it says is not
wrong, but it does /suggest/ that delete() on a queryset doesn't do anything
per-object, which is not true at all.

Perhaps I'll work on clarifying the docs and adding a warning that Django's
delete() on a queryset will chunk the actual deletions--in addition to
calling signals and deleting related objects one by one--so raw SQL should
be used instead if one needs to delete a lot of rows and efficiency is a
concern?  Does that seem reasonable?

Tobias

[1] http://docs.djangoproject.com/en/dev/topics/db/queries/#deleting-objects
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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.

Re: making queryset.delete issue only a single SQL query

[SmileyChris]

On Sep 11, 1:12 pm, Tobias McNulty  wrote:
> Hi All,
>
> I may be missing something, but queryset.delete() seems oddly implemented in
> Django.  It does a select to get all the IDs to be deleted, and then deletes
> them, in blocks of 100 I believe, by ID.

It's because .delete() is emulating the behavior of the SQL constraint
ON DELETE CASCADE

A list of objects to be deleted is recursively populated, then this
complete list of objects is iteratively deleted (also calling the
pre_delete and post_delete signals in their respective places).

-- 
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.