Re: Slow page load performance with a large number of formsets (over 25)

[Steven Smith]

What is hard reload?
On Monday, February 7, 2022 at 12:43:08 PM UTC-6 abdouli...@gmail.com wrote:

> Try hard reload it's little bit faster
>
> On Mon, Feb 7, 2022, 18:12 Steven Smith  wrote:
>
>> Did this issue ever get resolved?  I'm experiencing the same thing.  Once 
>> it hits 100 forms or so it gets pretty slow.
>>
>> On Monday, September 22, 2014 at 10:48:52 AM UTC-5 Collin Anderson wrote:
>>
>>> Yes, if you want speed, using javascript and ajax is probably your best 
>>> bet. It will probably also reduce merge-conflicts.
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/48609393-cb83-4eea-845b-d353e41af1e7n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-users/48609393-cb83-4eea-845b-d353e41af1e7n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/65b3ee86-64bb-4f64-894a-76fd62079097n%40googlegroups.com.

Re: Slow page load performance with a large number of formsets (over 25)

[Steven Smith]

Did this issue ever get resolved?  I'm experiencing the same thing.  Once 
it hits 100 forms or so it gets pretty slow.

On Monday, September 22, 2014 at 10:48:52 AM UTC-5 Collin Anderson wrote:

> Yes, if you want speed, using javascript and ajax is probably your best 
> bet. It will probably also reduce merge-conflicts.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/48609393-cb83-4eea-845b-d353e41af1e7n%40googlegroups.com.

Formsets

[Steven Smith]

Hello all!   

I find formsets wildly useful...but very difficult to architect.  I have 
them working...But I am running into a commonly documented problem...They 
are slow as you build up the number of fields and queries.  Are there any 
general tips that can be used or share on how to improve this issue?  I 
have tried all of the commonly prescribed 
solutions...select_related...prefetch_related...etc...But nothing seems to 
help.  

I realize that Queries take timebut I'm just trying to see if there is 
a way to streamline them a bit.  It seems to me that formsets use a lot of 
queries depending on the amount of data and that's the trade off. 

Again thanks for any thoughts or comments.

Steve

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/178a8ba4-e00c-44ac-ad29-b1b39bdea54fn%40googlegroups.com.

Best-practice for "join mailing list" form on every page

[Steven Smith]

I've got a simple form with one field that appears in the footer of my 
site, asking users to enter their email address to subscribe to our mailing 
list.

Rather than duplicate the form-processing logic in every single view, what 
should I do?
- POST to one location, but use a context processor to add the form in GET 
contexts?
- Add a decorator to every view that does the form logic
- Some other third option?

What do people typically do in this type of situation?


Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Design for storing likes/dislikes?

[Steven Smith]

I've used NullBooleanField for this before, as well.  A lot quicker to 
query on than a ManyToMany, also.



On Tuesday, July 16, 2013 9:24:54 PM UTC-4, donarb wrote:
>
> On Tuesday, July 16, 2013 5:29:47 PM UTC-7, Victor Hooi wrote:
>>
>> Hi,
>>
>> We have a list of users, who are going to like/dislike various widgets.
>>
>> My question is regarding how to store the like/dislikes.
>>
>> Essentially, there can be three states between a user and a widget - 
>> like, dislike, and unrated, so it's not just a straight Boolean.
>>
>> I'm thinking of just doing a M2M between user and widgets models, and 
>> then storing an extra field on that M2M.
>>
>> I can either store a Boolean, for whether the item is liked/unliked - and 
>> then an unrated item simply won't be exist in the table.
>>
>> Or I can store a integer (with a choice tupled defined), with say 
>> 0=unrated, 1=like, 2 = unlike, and all possible combinations are listed.
>>
>> We'll be doing queries to compare users, and see if their likes/dislikes 
>> intersect.
>>
>> Are there any pros/cons of the two approaches for this given query, or is 
>> there perhaps a more efficient way of storing this data?
>>
>> Cheers,
>> Victor
>>
>
>
>
> Django has a NullBooleanField that allows 3 states, Unknown (null), True, 
> False.
>
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.

Form Wizard: Redirecting back to a step from inside the done() method

[Steven Smith]

I have a form wizard that walks a user through some system configuration 
steps. In the done() method, the cleaned_data is used to call out to a 
configuration system to do various set/unset operations.

Most of the time, the validation that I have built into my form classes is 
sufficient. However, occasionally, the configuration system I am 
interfacing with will return validation errors of its own, and when this 
happens, I need to be able to return the user to a previous step in the 
form. Right now, all I've figured out how to do is redirect them back to 
the start of the form (using HttpResponseRedirect) but this of course loses 
their data.

Is there a way to redirect, from the done() method, back to an existing 
step of the form, in such a way that the data is not removed?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Weird problem generating forms on the fly

[Steven Smith]

I like it. Thanks, Tom!



On Mar 9, 11:19 am, Tom Evans <tevans...@googlemail.com> wrote:
> On Fri, Mar 9, 2012 at 4:05 PM, Steven Smith <ste...@stevenlsmith.com> wrote:
> > I think I figured it out. My TYPE_MAPPING thing was causing the form
> > fields to be initialized *once*. So, I made the contents of
> > TYPE_MAPPING into strings, and I'm using eval().
>
> > Unless there's a better way, I'm leaving it like this in
> > production :-)
>
> Just as an idea, you could specify TYPE_MAPPING as a factory, which
> would avoid eval():
>
> TYPE_MAPPING_FACTORY = {
>    'Date': lambda: forms.DateTimeField(required=True,
>        widget=forms.DateTimeInput({'class': 'datetime'})),
>    'String': lambda: forms.CharField(max_length=100, required=True),
>    'Long': lambda: forms.IntegerField(required=False),
>    'Integer': lambda: forms.IntegerField(required=False),
>    'Boolean': lambda: forms.BooleanField(required=False),
>
> }
>
> field = TYPE_MAPPING_FACTORY['String']()
>
> Cheers
>
> Tom

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Weird problem generating forms on the fly

[Steven Smith]

I think I figured it out. My TYPE_MAPPING thing was causing the form
fields to be initialized *once*. So, I made the contents of
TYPE_MAPPING into strings, and I'm using eval().

Unless there's a better way, I'm leaving it like this in
production :-)



On Mar 9, 10:01 am, Steven Smith <ste...@stevenlsmith.com> wrote:
> I have data that looks like this:
> formfields = [{'label': u'IP address of hacker', 'type': u'String',
> 'name': u'locationIp'}, {'label': u'Created end date', 'type':
> u'Date', 'name': u'createdEndDate'}, {'label': u'Created start date',
> 'type': u'Date', 'name': u'createdStartDate'}]
>
> I want to generate a forms.Form object from it, so I wrote the
> following code (ReportForm is just an empty declaration of a form
> class):
>
> -
>
> TYPE_MAPPING = {
>     'Date': forms.DateTimeField(required=True,
> widget=forms.DateTimeInput({'class': 'datetime'})),
>     'String': forms.CharField(max_length=100, required=True),
>     'Long': forms.IntegerField(required=False),
>     'Integer': forms.IntegerField(required=False),
>     'Boolean': forms.BooleanField(required=False),
>
> }
>
> def get_form_for_report(formfields, postdata=None):
>     if postdata:
>         form = ReportForm(postdata)
>     else:
>         form = ReportForm()
>     attrs = formfields.reverse()
>     for f in attrs:
>         form.fields.insert(1, f['name'], TYPE_MAPPING.get(f['type']))
>         form.fields[f['name']].label = f['label']
>     return form
>
> -
>
> However, when this code executes, the form generated works perfectly,
> but the label is not always set properly. In this particular example,
> I get two fields (with correct field names) that have the label
> "Created Start Date".
>
> Where I am going wrong here?

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Weird problem generating forms on the fly

[Steven Smith]

I have data that looks like this:
formfields = [{'label': u'IP address of hacker', 'type': u'String',
'name': u'locationIp'}, {'label': u'Created end date', 'type':
u'Date', 'name': u'createdEndDate'}, {'label': u'Created start date',
'type': u'Date', 'name': u'createdStartDate'}]

I want to generate a forms.Form object from it, so I wrote the
following code (ReportForm is just an empty declaration of a form
class):

-

TYPE_MAPPING = {
'Date': forms.DateTimeField(required=True,
widget=forms.DateTimeInput({'class': 'datetime'})),
'String': forms.CharField(max_length=100, required=True),
'Long': forms.IntegerField(required=False),
'Integer': forms.IntegerField(required=False),
'Boolean': forms.BooleanField(required=False),
}


def get_form_for_report(formfields, postdata=None):
if postdata:
form = ReportForm(postdata)
else:
form = ReportForm()
attrs = formfields.reverse()
for f in attrs:
form.fields.insert(1, f['name'], TYPE_MAPPING.get(f['type']))
form.fields[f['name']].label = f['label']
return form


-


However, when this code executes, the form generated works perfectly,
but the label is not always set properly. In this particular example,
I get two fields (with correct field names) that have the label
"Created Start Date".

Where I am going wrong here?

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Combining Querysets from different, but similar models

[Steven Smith]

I'm working on a site that has a requirement for a "recent activity"
feed on the homepage. Usually, I'd just do a MyFoo.objects.order_by('-
created') and all would be well. But "activity" is actually from
several models. They all have some fields in common, like the
timestamp, since they all have the same abstract base class, but
they're definitely different things.

What's the cheapest way to do my queries and mix the results into one
feed? Ideally, the name of the model, or some other differentiating
attribute would be exposed so that I can use it in my template loop as
a style hook. Models in question are below...


class TrackableModel(models.Model):
created = models.DateTimeField(auto_now_add=True)
modified = models.DateTimeField(auto_now=True)
created_by = models.ForeignKey(User, blank=True, null=True)
history = models.TextField(blank=True)
notes = models.TextField(blank=True)
is_active = models.BooleanField(blank=True, default=True)

class Meta:
abstract = True


class Review(TrackableModel):
book = models.ForeignKey('Textbook')
course = models.ForeignKey('TaughtCourse', blank=True, null=True)
should_buy = models.BooleanField(blank=True)
rating_prep = models.DecimalField(blank=True, null=True,
max_digits=2, decimal_places=1)
rating_hw = models.DecimalField(blank=True, null=True,
max_digits=2, decimal_places=1)
rating_inclass = models.DecimalField(blank=True, null=True,
max_digits=2, decimal_places=1)
can_share = models.BooleanField(blank=True, default=True)
comments = models.TextField(blank=True)


class MarketplacePosting(TrackableModel):
book = models.ForeignKey('Textbook', blank=True, null=True)
school = models.ForeignKey('School', blank=True, null=True)
location = models.CharField(max_length=255, blank=True,
verbose_name="Sale location")
condition = models.CharField(max_length=15, blank=True,
choices=CONDITION_CHOICES)
contains_highlighting = models.BooleanField(blank=True)
price = models.DecimalField(blank=True, null=True, max_digits=6,
decimal_places=2)
comments = models.TextField(blank=True)
is_sold = models.BooleanField(blank=True)

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Most stable Linux distribution for Django - Python development

[Steven Smith]

We're using Gentoo 64-bit on all of our production webservers at work,
and I run 4 additional Gentoo-based Django servers outside of work.

It took a long time to configure, and is not for the faint of heart.

But, my stripped-down versions of Apache and Postgres run really fast
with a small memory footprint. Gentoo provided the framework that made
these customizations easy (a lot easier to optimize things with USE
flags than low-level compile options...). Since I don't have a lot of
the bloat that is plaguing Linux these days, I can do system updates
infrequently and quickly. The full day it took me to get the server
set up has more than paid for itself by making long-term maintenance a
snap.




On Aug 1, 4:27 am, Anoop Thomas Mathew  wrote:
> Hi All,
> Firstly, I am not here for a distro war.
>
> I was using ubuntu 9.10, and then switched to fedora 14 and then to fedora
> 15.
> IMHO, It seems that they all were quite unstable. (Many times it hung up on
> my Dell and HP machines - may be driver issues, still I don't want that
> too.)
> I would really like some recommendation for a linux distro which is much
> stable, but still can support all relevant packages.
>
> Top recommendations I found around was Debian and OpenSuse.
> Please revert with your suggestions.
>
> Thanks,
> Anoop Thomas Mathew
>
> atm
> ___
> Life is short, Live it hard.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Accessing "request" from within an authentication backend

[Steven Smith]

Is there a way to access the HttpResponse, or issue a redirect from
within a custom authentication backend? I have Django hooked up to our
Active Directory server, and it works perfectly except when the user's
password expires or they have "User must change password at next
login" set on their account. In these circumstances, I'd like to be
able to spit out a message (using contrib.messages) stating that they
are required to change their password, and then (ideally) issue an
HttpResponseRedirect over to our "change password" website, which is,
coincidentally, on the same Django system, so the message would carry
over and stuff... but I need to be able to set it in the first place.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Intermittent OperationalError on multiple Django servers

[Steven Smith]

On two separate Django servers, I'm seeing variations on this error:


 File "/usr/lib64/python2.6/site-packages/django/db/models/sql/
compiler.py", line 731, in execute_sql
   cursor = self.connection.cursor()

 File "/usr/lib64/python2.6/site-packages/django/db/backends/
__init__.py", line 75, in cursor
   cursor = self._cursor()

 File "/usr/lib64/python2.6/site-packages/django/db/backends/
postgresql_psycopg2/base.py", line 136, in _cursor
   self.connection = Database.connect(**conn_params)

OperationalError: could not connect to server: Connection refused
   Is the server running on host "localhost" and accepting
   TCP/IP connections on port 5432?



99% of the time, the user agent is one of the search engines' bots, so
I don't think very many users are seeing it, but it's definitely
affecting my SEO, since, the search engine can't crawl the site. And
it makes me cringe every time I see the error emails...


Anybody have a nudge in the right direction as to where I might start
looking? This is Django 1.2.5 with Postgres 9.0.3, running on a 64-bit
linux system with Apache 2.2.16 and mod_wsgi 3.3.

Thanks!

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.