Tuesday, November 1, 2011

Image Model, Form and View -> Easily change "upload_to" path from form.save()?

Hey,

I've got a very simple setup for a sample application. Basically, I
have a Model w/ an ImageField. I have a ModelForm using that Model.
Finally, I have a FormView for using that Form.

In my View, I call my form's .save() method and pass along the request
user. I'd like to manipulate where this file is stored.

Here's what I tried so far but it did *not* work -- the thing just
uses the preset upload_to variable.

ImageForm.save(self, user):

# Grab Model Instance
m = super(ImageForm, self).save(commit = False)

# Try to Change "upload_to" Value
# Note: "data" is the name of my ImageField
m.data.upload_to = 'some_other_folder'

# Save the Model
m.save()

# Done
return m

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

Re: Suggestions on "Loading" for possible long load-times?

Thanks a lot Russel! It sounds like a pretty reasonable approach to me.

On Tue, Nov 1, 2011 at 7:54 PM, Russell Keith-Magee <russell@keith-magee.com> wrote:
On Wed, Nov 2, 2011 at 7:37 AM, Kurtis <kurtis.mullins@gmail.com> wrote:
> Hey,
>
> I've got a part of my site that is just prototyped at the moment. It's
> not particularly optimized since it's still in the works.
>
> I don't think it's going to take a considerable amount of time to load
> while we have few users. But, when we start migrating our old users to
> the new system, I can imagine there will be a delay before the
> calculations are finished and the data is ready to display.
>
> Unfortunately, this is real-time calculations so it's not a simple
> matter of caching it to death. I'm not ready to do any major
> optimization at this point anyways since it's still a work-in-
> progress.
>
> Anyways, I want to display a "loading" page while the data is
> prepared. I don't mind if it's a matter of a redirect, done using
> AJAX, or just using some sort of a Javascript technique that will
> display the "Loading" dialog while the rest of the data is sent to the
> browser. What are some suggestions on doing this with Django? I prefer
> a simple, straight-forward method that won't cause a lot of
> complication with the existing code base if at all possible.

There's a very common pattern for this kind of activity:

 1) User requests /start page to get some data that is expensive to calculate

 2) View for /start creates a Task object that represents the work to
be executed in the background.

 3) An external process is running, waiting for new Task objects to be
created. Exactly how this is serviced is up to you, but the important
part is that the expensive calculation isn't performed in the view
code -- it's handled by a process external to the web server. Celery
is a common way to handle this sort of task; you can also knock
something together quickly with a script running under a cron (run
once per minute, find all new tasks, process each, then quit. Not
ideal for production, but it works as a proof of concept).

 4) Once the task has been *created* (Not finished -- just created),
/start redirects to a /loading page.

 5) /loading contains an ajax lookup that polls the completion status
of the task

 6) The task executes and completes; on completion, the task is marked
as "complete".

 7) Once the task is complete, /loading reports the completion, and
redirects to /finished to display the results of the calculation.

At every step, the web server's interaction is short lived -- create a
task; check if the task is complete; display the result of the task --
so it scales well. If you're careful about the design of your task
processor, you can make sure that this processor scales too; e.g., add
a second Celery processor for the task, and you've just doubled your
capacity.

Hope this helps!

Yours,
Russ Magee %-)

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.


--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

Re: Can't locate Django source code path

To grab the entire source package, follow the instructions on this page:


To grab just that single HTML file, it can be found here:


Note, that there's different versions of Django so if you are using version 1.3, then you will have to go to the 1.3 release instead of using the "trunk". Good luck!

On Tue, Nov 1, 2011 at 10:43 PM, BillB1951 <wjburris@gmail.com> wrote:
FRom part 2 of the tutorial I am instructed to copy a file ---


Now copy the template admin/base_site.html from within the default
Django admin template directory in the source code of Django itself
(django/contrib/admin/templates) i

I can't find the path.  How do I get to it?

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.


--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

Re: Can't locate Django source code path

It will be in the "site-packages" directory of your Python installation.
For Windows, this is typically C:\Python27\Lib\site-packages\django. The
location varies based on operating system. You can always open the
python interpreter and run

>>> import sys
>>> sys.path

to get a clue where your PYthon installation is (look for a path which
includes 'site-packages').

On 11/1/2011 7:43 PM, BillB1951 wrote:
> FRom part 2 of the tutorial I am instructed to copy a file ---
>
>
> Now copy the template admin/base_site.html from within the default
> Django admin template directory in the source code of Django itself
> (django/contrib/admin/templates) i
>
> I can't find the path. How do I get to it?
>

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

Can't locate Django source code path

FRom part 2 of the tutorial I am instructed to copy a file ---


Now copy the template admin/base_site.html from within the default
Django admin template directory in the source code of Django itself
(django/contrib/admin/templates) i

I can't find the path. How do I get to it?

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

Re: Django aggregation does excessive GROUP BY clauses

On Tue, Nov 1, 2011 at 6:19 PM, christian.oudard <christian.oudard@gmail.com> wrote:
I am doing a very simple aggregation using the Django ORM, and it is
producing a GROUP BY clause that includes the data field, which is
very large, and is slowing down the query by over 100-fold.

Here is a simplified version of the model:

class Document(models.Model):
   data = models.TextField()

class Attachment(models.Model):
   document = models.ForeignKey(Document)

And the query I am running:

Document.objects.annotate(num_attachments=Count('attachment'))


The SQL generated by the ORM for this query changed between Django version 1.2 and 1.3. The 1.2 SQL did a group by only on the id field. With 1.3 we're getting id twice and then all other fields in the model. Bisection shows the change was made with r14715:

https://code.djangoproject.com/changeset/14715

It certainly looks to me like the old SQL was correct and preferable for this particular case. In a brief search I did not find a ticket reporting this issue -- could you open one?

Karen
--
http://tracey.org/kmt/

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

Re:Field available via Django shell but not via web application (crossposted from StackOverFlow)

Is this using the Django built in runserver or some other way of serving pages? If not try using runserver.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.