Re: Moving from django 1.3 to 1.9

[Alan]

Many thanks to you all guys, I will follow this path.

Alan

On 27 January 2017 at 22:05, bobhaugen  wrote:

> I agree with all the advice to go a step at a time.
>
> Here's a bunch of clues and chatter in github issues about how we upgraded
> from 1.4 to 1.8, one minor version at a time.
> https://github.com/FreedomCoop/valuenetwork/issues?q=is%3Aclosed+label%
> 3Aupgrade
>
> --
> 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-users/0d810dcd-9411-4259-9bdb-07144e073677%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Alan Wilter SOUSA da SILVA, DSc
Senior Bioinformatician, UniProt
European Bioinformatics Institute (EMBL-EBI)
European Molecular Biology Laboratory
Wellcome Trust Genome Campus
Hinxton
Cambridge CB10 1SD
United Kingdom
Tel: +44 (0)1223 494588

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAEznbz%3D3g0kP3aGrm3y91HkXpKr9DE33PaB-roJR_fUiLBhf5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Moving from django 1.3 to 1.9

[bobhaugen]

I agree with all the advice to go a step at a time. 

Here's a bunch of clues and chatter in github issues about how we upgraded 
from 1.4 to 1.8, one minor version at a time.
https://github.com/FreedomCoop/valuenetwork/issues?q=is%3Aclosed+label%3Aupgrade

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/0d810dcd-9411-4259-9bdb-07144e073677%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Moving from django 1.3 to 1.9

[Vinicius Assef]

I'd advise you to be aware of third-party libraries. Sometimes they are
dropped or can bring some incompatibilities.

On 27 January 2017 at 08:42, Andreas Kuhne 
wrote:

> I second this. Having moved from 1.3 to 1.9 in stages - I think this is
> the best way to do it. Upgrade one minor version at a time and it will
> probably be easiest.
>
> Regards,
>
> Andréas
>
> 2017-01-27 10:55 GMT+01:00 ludovic coues :
>
>> You might have an easier time upgrading from one version to the next.
>>
>> So first check if you have some deprecation warning and fix them. Then
>> install django 1.4, check if you have deprecation warnings, fix them.
>> Check things are working as intended. Test really help at this point.
>>
>> Once you are running on django 1.4 without deprecation warning or
>> regression, do the same with django 1.5 and so on. You might want to
>> follow the release note as you move along. Minor version release note
>> have a list of backwards incompatible change. See for exemple the
>> notes for django 1.4:
>> https://docs.djangoproject.com/en/1.10/releases/1.4/#backwar
>> ds-incompatible-changes-in-1-4
>>
>> Good luck with the upgrade and don't hesitate to ask question if you
>> have trouble at any point :)
>>
>> 2017-01-27 10:38 GMT+01:00 Alan :
>> > Hi there,
>> >
>> > Sorry for this question, we have created this service 5 years ago and
>> never
>> > touched since but now we want to move to a new server, with all updated
>> > software and even use python 3.5, I am wondering if there's any kind of
>> > "how-to" for it.
>> >
>> > Any help/suggestion is really appreciated.
>> >
>> > Thanks,
>> >
>> > Alan
>> >
>> > --
>> > Alan Wilter SOUSA da SILVA, DSc
>> > Senior Bioinformatician, UniProt
>> > European Bioinformatics Institute (EMBL-EBI)
>> > European Molecular Biology Laboratory
>> > Wellcome Trust Genome Campus
>> > Hinxton
>> > Cambridge CB10 1SD
>> > United Kingdom
>> > Tel: +44 (0)1223 494588
>> >
>> > --
>> > 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 https://groups.google.com/group/django-users.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msgid/django-users/CAEznbznSfxn9
>> H7tk%2BSs_qmpnBHYCajF6CeHfhpOH87vytx1vBA%40mail.gmail.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>>
>> Cordialement, Coues Ludovic
>> +336 148 743 42
>>
>> --
>> 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 https://groups.google.com/group/django-users.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/django-users/CAEuG%2BTY9Y0gK90-dZP%2BcrPMjk6qdFx%3DyWXiP
>> YqTwe6KL8hxKjw%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/django-users/CALXYUbkD04nnNEg-s5m2G1310hHxcAUjYn6QATq%2B
> dWRWQdEihg%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFmXjSABh7MvNUxNmLq47Y7RXXbpwS%3DQ__kSLzi57Txts%3D9njQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Moving from django 1.3 to 1.9

[Andreas Kuhne]

I second this. Having moved from 1.3 to 1.9 in stages - I think this is the
best way to do it. Upgrade one minor version at a time and it will probably
be easiest.

Regards,

Andréas

2017-01-27 10:55 GMT+01:00 ludovic coues :

> You might have an easier time upgrading from one version to the next.
>
> So first check if you have some deprecation warning and fix them. Then
> install django 1.4, check if you have deprecation warnings, fix them.
> Check things are working as intended. Test really help at this point.
>
> Once you are running on django 1.4 without deprecation warning or
> regression, do the same with django 1.5 and so on. You might want to
> follow the release note as you move along. Minor version release note
> have a list of backwards incompatible change. See for exemple the
> notes for django 1.4:
> https://docs.djangoproject.com/en/1.10/releases/1.4/#
> backwards-incompatible-changes-in-1-4
>
> Good luck with the upgrade and don't hesitate to ask question if you
> have trouble at any point :)
>
> 2017-01-27 10:38 GMT+01:00 Alan :
> > Hi there,
> >
> > Sorry for this question, we have created this service 5 years ago and
> never
> > touched since but now we want to move to a new server, with all updated
> > software and even use python 3.5, I am wondering if there's any kind of
> > "how-to" for it.
> >
> > Any help/suggestion is really appreciated.
> >
> > Thanks,
> >
> > Alan
> >
> > --
> > Alan Wilter SOUSA da SILVA, DSc
> > Senior Bioinformatician, UniProt
> > European Bioinformatics Institute (EMBL-EBI)
> > European Molecular Biology Laboratory
> > Wellcome Trust Genome Campus
> > Hinxton
> > Cambridge CB10 1SD
> > United Kingdom
> > Tel: +44 (0)1223 494588
> >
> > --
> > 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 https://groups.google.com/group/django-users.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/django-users/CAEznbznSfxn9H7tk%2BSs_
> qmpnBHYCajF6CeHfhpOH87vytx1vBA%40mail.gmail.com.
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
>
> Cordialement, Coues Ludovic
> +336 148 743 42
>
> --
> 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-users/CAEuG%2BTY9Y0gK90-dZP%2BcrPMjk6qdFx%
> 3DyWXiPYqTwe6KL8hxKjw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CALXYUbkD04nnNEg-s5m2G1310hHxcAUjYn6QATq%2BdWRWQdEihg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Moving from django 1.3 to 1.9

[ludovic coues]

You might have an easier time upgrading from one version to the next.

So first check if you have some deprecation warning and fix them. Then
install django 1.4, check if you have deprecation warnings, fix them.
Check things are working as intended. Test really help at this point.

Once you are running on django 1.4 without deprecation warning or
regression, do the same with django 1.5 and so on. You might want to
follow the release note as you move along. Minor version release note
have a list of backwards incompatible change. See for exemple the
notes for django 1.4:
https://docs.djangoproject.com/en/1.10/releases/1.4/#backwards-incompatible-changes-in-1-4

Good luck with the upgrade and don't hesitate to ask question if you
have trouble at any point :)

2017-01-27 10:38 GMT+01:00 Alan :
> Hi there,
>
> Sorry for this question, we have created this service 5 years ago and never
> touched since but now we want to move to a new server, with all updated
> software and even use python 3.5, I am wondering if there's any kind of
> "how-to" for it.
>
> Any help/suggestion is really appreciated.
>
> Thanks,
>
> Alan
>
> --
> Alan Wilter SOUSA da SILVA, DSc
> Senior Bioinformatician, UniProt
> European Bioinformatics Institute (EMBL-EBI)
> European Molecular Biology Laboratory
> Wellcome Trust Genome Campus
> Hinxton
> Cambridge CB10 1SD
> United Kingdom
> Tel: +44 (0)1223 494588
>
> --
> 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAEznbznSfxn9H7tk%2BSs_qmpnBHYCajF6CeHfhpOH87vytx1vBA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAEuG%2BTY9Y0gK90-dZP%2BcrPMjk6qdFx%3DyWXiPYqTwe6KL8hxKjw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Moving from django 1.3 to 1.9

[Alan]

Hi there,

Sorry for this question, we have created this service 5 years ago and never
touched since but now we want to move to a new server, with all updated
software and even use python 3.5, I am wondering if there's any kind of
"how-to" for it.

Any help/suggestion is really appreciated.

Thanks,

Alan

-- 
Alan Wilter SOUSA da SILVA, DSc
Senior Bioinformatician, UniProt
European Bioinformatics Institute (EMBL-EBI)
European Molecular Biology Laboratory
Wellcome Trust Genome Campus
Hinxton
Cambridge CB10 1SD
United Kingdom
Tel: +44 (0)1223 494588

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAEznbznSfxn9H7tk%2BSs_qmpnBHYCajF6CeHfhpOH87vytx1vBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Crente usar o django 1.3

[Daniel Roseman]

On Saturday, 26 September 2015 12:29:24 UTC+1, Carlos Andre wrote:
>
> Hi to all, i want creat a new user in any time without admin interface, i 
> dont know use the functions from User modules. 
> Thanks to help
>

Then you should read the documentation, or the code.
And you should upgrade your Django version; that one is four years old, and 
completely insecure and unsupported.
--
DR. 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/800f4476-f062-44f1-9893-3db140ff4c41%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Crente usar o django 1.3

[Carlos Andre]

Hi to all, i want creat a new user in any time without admin interface, i
dont know use the functions from User modules.
Thanks to help

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAA8yBMz1P%3Dx-OnkNMLmpvubMHXAhnW8njLCE2xwTWpLQiYSn-A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

integrity error with transaction middleware, django 1.3

[Brian Craft]

I'm getting duplicate entry integrity errors when saving an object, with
transaction middleware enabled in django 1.3.

I thought the point of the middleware was to rollback transaction errors
and retry the view. Why would I be getting this error?

The db is mysql. The save code looks like this:

try:
gs = request.user.usergeneset_set.get(name=name)
gs.genelist = members
except ObjectDoesNotExist:
gs = UserGeneset(user=request.user, name=name, genelist=members)
gs.save()

-- 
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: Should anyone be using Django 1.3 in production at this point?

[Bjorn Tipling]

Thank you for the reply. Upgrading as soon as possible makes the most sense.

On Wednesday, July 24, 2013 12:03:49 PM UTC-7, Bjorn Tipling wrote:
>
> The django downloads section says versions of Django 1.3 are no longer 
> supported with bug and security fixes. Obviously nobody ought to start a 
> new project with Django 1.3, but is it critical to update? Since the 
> release updates are broken down by version, it isn't clear to me if any of 
> the issues that affect 1.4 or 1.5 also affect 1.3.
>
> https://docs.djangoproject.com/en/1.3/releases/
>
> I also do not see any security fixes since the 1.3 deprecation.
>
> Thanks,
>
> Bjorn
>

-- 
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: Should anyone be using Django 1.3 in production at this point?

[Russell Keith-Magee]

On Thu, Jul 25, 2013 at 3:03 AM, Bjorn Tipling wrote:

> The django downloads section says versions of Django 1.3 are no longer
> supported with bug and security fixes. Obviously nobody ought to start a
> new project with Django 1.3, but is it critical to update? Since the
> release updates are broken down by version, it isn't clear to me if any of
> the issues that affect 1.4 or 1.5 also affect 1.3.
>
> https://docs.djangoproject.com/en/1.3/releases/
>

I'd say yes, it's a good idea to update when you have a chance.

The reason for this? You don't know when the next security issue will be
announced. When (and unfortunately, despite our best efforts, it is a
matter of when, not if) the next security problem is announced, you don't
want to be scrambling to update to 1.4 *and* fix the security issue, or
trying to manually back port the security issue to 1.3. If you're up to
date, you just have to update your requirements file or deployment script.
If you're still on 1.3, you have a lot of work to do, and you may need to
do it quickly because the exploit will be in the wild, and you might be
exposed to a problem.

It's impossible to say for certain if a problem found in 1.4 will also
affect 1.3 without knowing specifics, but broadly speaking, it's safe to
assume that it will -- past history with security problem has demonstrated
that the problems that are found aren't glaring problems with newly added
features -- they're deeply embedded edge case problems that have existed
for several versions. For example, our most recent security release (1.4.2
[1]) described a class of problem that has existed since Django was first
released.

[1] https://docs.djangoproject.com/en/dev/releases/1.4.2/

I also do not see any security fixes since the 1.3 deprecation.
>

Correct. To date, we haven't announced any security problems that haven't
been backported to 1.3.

The way you can check this -- if there was a point release in the 1.5 tree
that included a security patch, that patch would be included in 1.4, but
would *not* be back ported. We're currently sitting at 1.5.1, and the .1
patch release was to address a memory leak and two other small problems
identified in the 1.5.0 release [2] [3].

[2] https://docs.djangoproject.com/en/dev/releases/1.5.1/
[3] https://www.djangoproject.com/weblog/2013/mar/28/django-151/

Yours,
Russ Magee %-)

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

Should anyone be using Django 1.3 in production at this point?

[Bjorn Tipling]

The django downloads section says versions of Django 1.3 are no longer 
supported with bug and security fixes. Obviously nobody ought to start a 
new project with Django 1.3, but is it critical to update? Since the 
release updates are broken down by version, it isn't clear to me if any of 
the issues that affect 1.4 or 1.5 also affect 1.3.

https://docs.djangoproject.com/en/1.3/releases/

I also do not see any security fixes since the 1.3 deprecation.

Thanks,

Bjorn

-- 
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: Application Migration form Django 1.3 to Django 1.5

[Sandeep kaur]

On Mon, Jun 17, 2013 at 11:23 AM, Some Developer
 wrote:
> On 16/06/2013 21:24, Andreas Kuhne wrote:
>>
>> Apart from that there are a couple of small things that didn't work. We
>> had procedure based views, they had to be migrated to class based instead.
>
>
> You can still use function based views in Django 1.5. There is no need to
> migrate unless you really want to. If you have an already existing app that
> uses function based views you might find that migrating is just an
> unnecessary waste of time.
>
Yes there are barely few changes that need to be made. There is a
urls.py file where we need to change the direct_to_template to
template_view and in html file change the ones with like {% url login
%} to {% url 'login ' %}.
Thank you @Andreas and some developer for helping me out.
Or to make it little easy for other apps, we can make a script for this.

-- 
Sandeep Kaur
E-Mail: mkaurkha...@gmail.com
Blog: sandymadaan.wordpress.com

-- 
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: Application Migration form Django 1.3 to Django 1.5

[Some Developer]

On 16/06/2013 21:24, Andreas Kuhne wrote:

Apart from that there are a couple of small things that didn't work. We
had procedure based views, they had to be migrated to class based instead.


You can still use function based views in Django 1.5. There is no need 
to migrate unless you really want to. If you have an already existing 
app that uses function based views you might find that migrating is just 
an unnecessary waste of time.


--
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: Application Migration form Django 1.3 to Django 1.5

[Some Developer]

On 16/06/2013 21:13, Sandeep kaur wrote:

I have this Web application made in Django 1.3. And now when I use it
on Django 1.5, it does not work. It give error as no module simple.
So, Is there any migration tool
to make my application work easily on 1.5 version without manually
making lot of changes?
You help will be appreciated.



The most annoying changes you are going to have to make are likely URL 
tags in templates. You'll need to change all {% url url_name %} to {% 
url "url_name" %}. Depending on how many templates you have this might 
take awhile :).


--
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: Application Migration form Django 1.3 to Django 1.5

[Russell Keith-Magee]

On Mon, Jun 17, 2013 at 4:13 AM, Sandeep kaur  wrote:

> I have this Web application made in Django 1.3. And now when I use it
> on Django 1.5, it does not work. It give error as no module simple.
> So, Is there any migration tool
> to make my application work easily on 1.5 version without manually
> making lot of changes?
>

Upgrading from Django 1.3 to Django 1.5 shouldn't be a major problem, and
certainly shouldn't require a migration tool. There may be some minor
changes required in your templates (around the {% url %} tag), but
otherwise the code should run pretty much exactly the same. The error
you're describing is a problem with imports, and that *isn't* something
that has changed between Django versions.

In particular, your error message is talking about a module called
"simple". There's only one Django module with that name --
django.test.simple. To the best of my knowledge, that module didn't change
significantly between Django 1.3 and 1.5 -- certainly not in any way that
would result in an import error.

This suggests that the problem lies in either your own code, or in your
development environment. The fact that imports are now failing suggests
that it is the development environment that is the problem. Check all the
changes you've made that may affect import paths. If you're getting import
errors, open a Python shell and try to perform the import. If it doesn't
work at the shell, it won't work in a Django web server either.

Without any more details, it's near impossible to provide more help.
However, suffice to say that Django takes it's backwards compatibility very
seriously, and as long as you're using Django as documented, upgrading
between versions should not be a major problem.

Yours,
Russ Magee %-)

-- 
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: Application Migration form Django 1.3 to Django 1.5

[Andreas Kuhne]

2013/6/16 Sandeep kaur 

> I have this Web application made in Django 1.3. And now when I use it
> on Django 1.5, it does not work. It give error as no module simple.
> So, Is there any migration tool
> to make my application work easily on 1.5 version without manually
> making lot of changes?
> You help will be appreciated.
>
> --
> Sandeep Kaur
> E-Mail: mkaurkha...@gmail.com
> Blog: sandymadaan.wordpress.com
>
> --
> 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.
>
>
> Hi,

I did exactly the same thing a while back. Unfortunately there isn't any
easy way to do what you want. What I would recommend is to first migrate
the settings so that they represent the new way of setting up a django
project. The way I did that, was I created a new django project with 1.5
and just made sure that the settings where in the same place in the old
project.

Apart from that there are a couple of small things that didn't work. We had
procedure based views, they had to be migrated to class based instead.

You will have to migrate everything slowly and test, test, test

Regards,

Andréas

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

Application Migration form Django 1.3 to Django 1.5

[Sandeep kaur]

I have this Web application made in Django 1.3. And now when I use it
on Django 1.5, it does not work. It give error as no module simple.
So, Is there any migration tool
to make my application work easily on 1.5 version without manually
making lot of changes?
You help will be appreciated.

-- 
Sandeep Kaur
E-Mail: mkaurkha...@gmail.com
Blog: sandymadaan.wordpress.com

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

[Django 1.3] list_display, __unicode__ and sorting

[Micky Hulse]

Hello,

Would the below be an OK way to sort __unicode__ in the admin list_display?

Model:

def uni_sort(self):

return self.__unicode__()

uni_sort.admin_order_field = 'sort'
uni_sort.short_description = _(u'name')

Admin:

list_display = ('uni_sort', 'parent', 'name', 'slug',)

...

To save ya'll some time, the docs say:

[[

The __str__() and __unicode__() methods are just as valid in
list_display as any other model method, so it's perfectly OK to do
this:

list_display = ('__unicode__', 'some_other_field')

Usually, elements of list_display that aren't actual database fields
can't be used in sorting (because Django does all the sorting at the
database level).

However, if an element of list_display represents a certain database
field, you can indicate this fact by setting the admin_order_field
attribute of the item.

]]

Unless I'm mistaken, this does not work:

__unicode__.admin_order_field = 'sort'

Otherwise I could just do this:

list_display = ('__unicode__', 'parent', 'name', 'slug',)

My question:

Is it overkill to create a method, that returns the __unicode__ value,
just for the sake of being able to order on the "sort" field?

Thanks!

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

Re: ipython 0.11 with django 1.3 /in virtualenv

[Martin]

This comment explains why it is not loaded: 
https://code.djangoproject.com/ticket/17078#comment:8

Not sure how to go on from that though.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/_UdpKoy55m4J.
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: ipython 0.11 with django 1.3 /in virtualenv

[Martin]

I have the very same problem and can't figure out what's wrong...

First I created a profile for ipython and edited the ipython_config.py, 
which gets executed when I launch 'ipython'.
But when I start manage.py shell or shell_plus it's not executed (I still 
get the Django iPython shell though).
When I check for the python version it matches.

Any hint? Would be great :)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/t0tkw5MntfMJ.
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.

django 1.3 google3 statics files not found

[sandeez]

Hi I am newbie to django in google3 app engine. I am currently working on a 
project and am using django 1.3 in appengine. Everytime I build the 
project, statics are not found. Please suggest any settings required for 
this.I have refferred following link to build the project. 
https://sites.google.com/a/google.com/django/home/hosting-platforms/app-engine

Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/LLoO3FHXntYJ.
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.

[ANN] Django 1.3 bugfix release

[James Bennett]

Today we've issued Django 1.3.3, a quick bugfix release which restores
Python 2.4 compatibility in the Django 1.3 release series:

https://www.djangoproject.com/weblog/2012/aug/01/django-13-bugfix-release/

Affected users are encouraged to upgrade.

-- 
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: 'CSRF verification failed." from django.contrib.comments. can you help solve it? django 1.3

[brycenesbitt]

It works now that I have fully uninstalled pybbm.
Pybbm was incompatible with my app because it also extended the User
object (something apparently you can only do once?)

-- 
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: Django 1.3 to 1.4

[JJ Zolper]

Or I thought it would be okay until I saw these errors when trying to run 
my server:

Traceback (most recent call last):
  File "manage.py", line 14, in 
execute_manager(settings)
  File 
"/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 459, in execute_manager
utility.execute()
  File 
"/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 382, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File 
"/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", 
line 196, in run_from_argv
self.execute(*args, **options.__dict__)
  File 
"/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", 
line 217, in execute
translation.activate('en-us')
  File 
"/usr/local/lib/python2.7/dist-packages/django/utils/translation/__init__.py", 
line 105, in activate
return _trans.activate(language)
  File 
"/usr/local/lib/python2.7/dist-packages/django/utils/translation/trans_real.py",
 
line 194, in activate
_active.value = translation(language)
  File 
"/usr/local/lib/python2.7/dist-packages/django/utils/translation/trans_real.py",
 
line 183, in translation
default_translation = _fetch(settings.LANGUAGE_CODE)
  File 
"/usr/local/lib/python2.7/dist-packages/django/utils/translation/trans_real.py",
 
line 160, in _fetch
app = import_module(appname)
  File "/usr/local/lib/python2.7/dist-packages/django/utils/importlib.py", 
line 35, in import_module
__import__(name)
  File 
"/usr/local/lib/python2.7/dist-packages/django/contrib/admin/__init__.py", 
line 3, in 
from django.contrib.admin.helpers import ACTION_CHECKBOX_NAME
  File 
"/usr/local/lib/python2.7/dist-packages/django/contrib/admin/helpers.py", 
line 2, in 
from django.contrib.admin.util import (flatten_fieldsets, lookup_field,
  File 
"/usr/local/lib/python2.7/dist-packages/django/contrib/admin/util.py", line 
1, in 
from django.db import models
  File "/usr/local/lib/python2.7/dist-packages/django/db/__init__.py", line 
40, in 
backend = load_backend(connection.settings_dict['ENGINE'])
  File "/usr/local/lib/python2.7/dist-packages/django/db/__init__.py", line 
34, in __getattr__
return getattr(connections[DEFAULT_DB_ALIAS], item)
  File "/usr/local/lib/python2.7/dist-packages/django/db/utils.py", line 
92, in __getitem__
backend = load_backend(db['ENGINE'])
  File "/usr/local/lib/python2.7/dist-packages/django/db/utils.py", line 
51, in load_backend
raise ImproperlyConfigured(error_msg)
django.core.exceptions.ImproperlyConfigured: 'postgresql_psycopg2' isn't an 
available database backend.
Try using django.db.backends.postgresql_psycopg2 instead.
Error was: No module named postgresql_psycopg2.base


On Wednesday, July 11, 2012 10:40:30 PM UTC-4, JJ Zolper wrote:
>
> I made the mistake of not deleting the previous django files before I 
> installed django 1.4
>
> When I run:
>
> >>> import django
> >>> print(django.get_version())
> 1.4
>
> I see that. I'm sure I'm going beyond naive here but I just didn't want to 
> assume that my django would be fine if I didn't uninstall 1.3 first?
>
> I was able to run:
>
> python -c "import sys; sys.path = sys.path[1:]; import django; 
> print(django.__path__)"
>
> "If you previously installed Django using python setup.py install, 
> uninstalling is as simple as deleting the django directory from your 
> Pythonsite-packages. To find the directory you need to remove, you can 
> run the following at your shell prompt (not the interactive Python prompt):"
>
> and read that ^ but when I tried to delete the "django" directory returned 
> errors when I tried to remove it in the "dist-packages" directory.
>
> On the Django site and in the quote above it says "site-packages" but 
> there is nothing in that for me.
>
> I'm probably fine just wanted to post this.
>
> Thanks,
>
> JJ
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/zHizEb0Z-80J.
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.

Django 1.3 to 1.4

[JJ Zolper]

I made the mistake of not deleting the previous django files before I 
installed django 1.4

When I run:

>>> import django
>>> print(django.get_version())
1.4

I see that. I'm sure I'm going beyond naive here but I just didn't want to 
assume that my django would be fine if I didn't uninstall 1.3 first?

I was able to run:

python -c "import sys; sys.path = sys.path[1:]; import django; 
print(django.__path__)"

"If you previously installed Django using python setup.py install, 
uninstalling is as simple as deleting the django directory from your Python
site-packages. To find the directory you need to remove, you can run the 
following at your shell prompt (not the interactive Python prompt):"

and read that ^ but when I tried to delete the "django" directory returned 
errors when I tried to remove it in the "dist-packages" directory.

On the Django site and in the quote above it says "site-packages" but there 
is nothing in that for me.

I'm probably fine just wanted to post this.

Thanks,

JJ

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/HavKSz5MKLkJ.
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: 'CSRF verification failed." from django.contrib.comments. can you help solve it? django 1.3

[Melvyn Sopacua]

On 30-6-2012 8:39, brycenesbitt wrote:

> {% csrf_token %}
> 
> I render my form with:
> {% render_comment_form for entry %}

You should verify if the generated html looks sane. If you need help
with that, put it up on dpaste.

> ---
> I should note it did work when I first added it to the application.  It 
> broke after I added pybbm.  I've since removed pybbm (it is maintained and 
> broken), but comments
> started getting csrf errors.

Any chance pybbm started messing with the session storage backend and
you haven't set it back correctly? Do any sessions work at all?

-- 
Melvyn Sopacua


-- 
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: 'CSRF verification failed." from django.contrib.comments. can you help solve it? django 1.3

[brycenesbitt]

On Thursday, June 28, 2012 10:43:58 AM UTC-7, jonas wrote:
>
> After the starting form tag add {% csrf_token %} 
>

I can't.
It is rendered for me by {% render_comment_form for entry %}

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/P_1zIG9fUC4J.
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: 'CSRF verification failed." from django.contrib.comments. can you help solve it? django 1.3

[brycenesbitt]

The "security_hash" field that you see is part of the comments app, and is 
> not the CSRF token. That needs to be output by a {% csrf_token %} tag (or 
> its equivalent). If it's working, you should see another hidden input 
> field, which looks like this:
>
> 
>  value="36d43c1652d5676d6d411950e077eeaa1cc1f799"/>
> 
>
> The comments app normally does that automatically -- it's part of 
> django/contrib/comments/templates/form.html -- Are you overriding the 
> comment form in your own app? If so, you need to include the call to {% 
> csrf_token %} yourself.
>

I am not overriding, at least not deliberately.

django/contrib/comments/templates/form.html has:
{% load comments i18n %}
{% csrf_token %}

I render my form with:
{% render_comment_form for entry %}

---
I should note it did work when I first added it to the application.  It 
broke after I added pybbm.  I've since removed pybbm (it is maintained and 
broken), but comments
started getting csrf errors.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/pykynQInFVUJ.
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: 'CSRF verification failed." from django.contrib.comments. can you help solve it? django 1.3

[Ian Clelland]

On Thu, Jun 28, 2012 at 9:14 AM, brycenesbitt 
 wrote:

> I'm using django.contrib.comments and get 'CSRF token missing or
> incorrect.' when previewing or submitting a comment.  I have:

...



The HTML looks like it has the csrf security_hash in the proper place:
> 
>  />
> 
> 
> ...



The "security_hash" field that you see is part of the comments app, and is
not the CSRF token. That needs to be output by a {% csrf_token %} tag (or
its equivalent). If it's working, you should see another hidden input
field, which looks like this:





The comments app normally does that automatically -- it's part of
django/contrib/comments/templates/form.html -- Are you overriding the
comment form in your own app? If so, you need to include the call to {%
csrf_token %} yourself.

@csrf_protect  #does not matter if this is here or not
>

No, if you have the CSRFViewMiddleware installed, then you don't need this
line at all.

-- 
Regards,
Ian Clelland


-- 
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: 'CSRF verification failed." from django.contrib.comments. can you help solve it? django 1.3

[Jonas Geiregat]

On do, jun 28, 2012 at 09:14:36 -0700, brycenesbitt wrote:
> http://127.0.0.1:8000/comments/post/>" method="post">
>/>
>id="id_timestamp" />
>value="6e85e1c846861c80575ce435b21a855706725b00" id="id_security_hash" 
> />

After the starting form tag add {% csrf_token %}

More information about it: 
https://docs.djangoproject.com/en/dev/ref/contrib/csrf/

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

'CSRF verification failed." from django.contrib.comments. can you help solve it? django 1.3

[brycenesbitt]

I'm using django.contrib.comments and get 'CSRF token missing or incorrect.' 
when previewing or submitting a comment.  I have:

*MIDDLEWARE_CLASSES = (*
*'django.middleware.csrf.CsrfViewMiddleware',*
*'django.middleware.common.CommonMiddleware',*
*'django.contrib.sessions.middleware.SessionMiddleware',*
*'django.contrib.auth.middleware.AuthenticationMiddleware',*
*'django.contrib.messages.middleware.MessageMiddleware',*
*)*

url(r'^comments/',  include('django.contrib.comments.urls')),
url(r'^entry/(?P\d+)/comment',  'rp2.views.entry_comment_add'),

@csrf_protect  #does not matter if this is here or not
def entry_comment_add(request, pk):
entry = models.Entry.objects.get(pk=pk)
assert isinstance(entry, models.Entry)
return render(request, 'entry_comment_popup.html', {'entry':entry})

{% extends 'head-plain.html' %}

{% load comments %}
{% block content %}
{% render_comment_form for entry %}
{% endblock %}

The HTML looks like it has the csrf security_hash in the proper place:

http://127.0.0.1:8000/comments/post/>" method="post">
  
  
  

...

I have read https://docs.djangoproject.com/en/dev/ref/contrib/comments/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/TDG0eAHHlkkJ.
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.

Django 1.3 with soaplib2.0

[Jeff Silverman]

I'm trying to use the soaplib 2.0 web service snippet example and
continue to receive a 405 method not allowed error when trying to
access the method.  I coded the example as is, with the views.py and
urls.py exactly as shown.  I'm new to web services, so I know i've
missed something, but I cannot seem to determine what?

I would sure appreciate any help or understanding of what's missing.

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

SOLVED: Django 1.3 Admin Changelist column alignment

[kooliah]

I solved cloning and renaming the templatetag result_list (the rows 
builder) and modifying it.
It checks if the field is a number and set the class attribute  of the 
 tag to "numb", so using the admin css i can change alignment
Obviously i had to override change_list.html too to let it load my 
custom template tag.


It works, but i'm surprising that a so common functionality (everywhere 
numbers are right justify) needs a so complex customization..


I'm sure to have miss something and there is a simpler  way to do it...

If someone has better idea or solution i'm very happy to know

Thanks anyway to all



On 06/17/2012 02:55 PM, kooliah wrote:
I'm trying to change alignment of the number columns in the 
changelist, instead of default left alignment for all, i would like to 
have left for the text and right for the numbers.
Is it possible to do it in the admin.py overriding the default class 
or i have to make some filters and apply to the template?


Overriding i can change the format or the column displayed using a 
callable, so i tryed to rjust the number (converted to string and 
thousand separated) using a function but i think it is trimmed again 
later



Can someone point me in the right direction?

Thanks to all

Kooliah



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

Django 1.3 Admin Changelist column alignment

[kooliah]

I'm trying to change alignment of the number columns in the changelist, 
instead of default left alignment for all, i would like to have left for 
the text and right for the numbers.
Is it possible to do it in the admin.py overriding the default class or 
i have to make some filters and apply to the template?


Overriding i can change the format or the column displayed using a 
callable, so i tryed to rjust the number (converted to string and 
thousand separated) using a function but i think it is trimmed again 
later



Can someone point me in the right direction?

Thanks to all

Kooliah

--
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: SOLVED Django 1.3 Ordering by two or more fields workaround ??

[kooliah]

Solved working on admin instead of models, in the following way

- admin.py--
class SpecialOrderingChangeList(ChangeList):
'''
Django 1.3 ordering problem workaround
from 1.4 it's enough using ordering var
'''
def get_query_set(self):
queryset = super(SpecialOrderingChangeList, self).get_query_set()
return queryset.order_by(*self.model._meta.ordering)

class CollectionAdmin(admin.ModelAdmin):
list_display = ('collection_prdct','ordr', 'product')

def get_changelist(self, request, **kwargs):
return SpecialOrderingChangeList
end - admin.py--

Now the list_display of admin is ordered by all the fields in 
meta.ordering not only by the first



--
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: Django 1.3 Ordering by two or more fields workaround ??

[kooliah]

On 06/03/2012 02:41 PM, kooliah wrote:


def _merged_field(self):
  return u'%s%i' % (self.collection_prdct, self.order)
merged_field = property(_merged_field)

and change
ordering = ('collection_prdct','ordr',)
to
ordering = ('merged_field',)

but it gives me
"ordering" refers to "mergedfield", a field that doesn't exist.


Sorry I mistake the pasted code the correct one is

def _mergedfield(self):
return u'%s%i' % (self.collection_prdct, self.ordr)
mergedfield = property(_mergedfield)% (self.collection_prdct, 
self.product)


class Meta:
ordering = ('mergedfield',)

Otherwise it would seem a stupid syntax error :-)




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

Django 1.3 Ordering by two or more fields workaround ??

[kooliah]

I'm working on Satchmo, which last version require django 1.3,

http://www.satchmoproject.com/docs/dev/requirements.html

but with 1.3 there is an ordering problem as said here:

https://docs.djangoproject.com/en/dev/ref/models/options/#ordering

"Changed in Django 1.4: The Django admin honors all elements in the 
list/tuple; before 1.4, only the first one was respected."


So i have

-models.py-
class Collection(models.Model):
collection_prdct = models.ForeignKey(Product, verbose_name=_('Base 
Product'), related_name="test_cllctn", on_delete=models.PROTECT)
product = models.ForeignKey(Product, verbose_name=_('Collection 
Product'), on_delete=models.PROTECT)

qta = models.IntegerField(default=1, verbose_name=_('Quantity'))
discount = models.ForeignKey(Discount, verbose_name=_('Discount'))
ordr = models.IntegerField(_("Ordering"), default=0, 
help_text=_("Shipping order"))


def __unicode__(self):
return u"Coll.: %s - %s" % (self.collection_prdct, 
self.product)


class Meta:
ordering = ('collection_prdct','ordr',)
verbose_name = _('Collection model')
verbose_name_plural = _('Collection models')
end 
-models.py-


I think that i can do a callable that return a virtual merged field 
which order on...

something like

def _merged_field(self):
  return u'%s%i' % (self.collection_prdct, self.order)
merged_field = property(_merged_field)

and change
ordering = ('collection_prdct','ordr',)
to
ordering = ('merged_field',)

but it gives me
"ordering" refers to "mergedfield", a field that doesn't exist.

Do i miss something?...or
What is the best way to have it order by two or more fields, expecially 
in the admin list_view?


Thanks to all
Kooliah





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

Django 1.3 online documentation ... error? ... quibble?

[Kevin Cole]

Hi,

I'm once again attacking the Django with vigor. And THIS time, I've 
actually got some forward momentum and am approximating progress! Yay! ;-)

In reading "Creating forms from models" 
(https://docs.djangoproject.com/en/1.3/topics/forms/modelforms/) I note the 
mention of a model field called PhoneNumberField.  However. searching all 
the model documentation, I find no such mention of that field type.  In 
fact, a search of the term results in only two hits: the aforementioned 
page, and "The local flavor add-ons" page 
(https://docs.djangoproject.com/en/1.3/ref/contrib/localflavor/)

So, is there such a model field, and if so, where is it documented?

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/y6yozCDgTFcJ.
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.

Upgrading from django 1.3 to django 1.4 -- timezone support

[Rajat Jain]

Hi,

I have a MySQL 5.5 backend and I use it via the Django 1.3 framework. I am 
trying to switch to Django 1.4, but want to know how it will affect me. 
Currently I store all the timezones in PST.

As far as I understand from reading the documents, if I upgrade to 1.4 and 
keep the USE_TZ = False option in my settings.py, then my app should work 
as it worked in 1.3 and no side effect should occur. Am I correct?

Thanks,
Rajat

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/GXd_GOuoEDwJ.
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: Is it able to nest block in a conditional tag in the template of Django 1.3?

[Tom Evans]

On Wed, Feb 29, 2012 at 7:20 AM, Patto  wrote:
> Here is my need:
>
> {% if request.user.is_csr %}
>       {% block csr_block %}
>
>
>
> {% endif %}
>

No. Inside child templates, most nodes outside of blocks are ignored.
You can do this instead:

{% block csr_block %}
{% if request.user.is_csr %}
...
{% else %}
{{ block.super }}
{% endif %}
{% endblock %}

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.

Is it able to nest block in a conditional tag in the template of Django 1.3?

[Patto]

Here is my need:

{% if request.user.is_csr %}
  {% block csr_block %}



{% endif %}

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/GwJ0AOf-DYYJ.
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: "DatabaseError: can't adapt type 'NavigableString'" when using psycopg2 and Django 1.3

[kenneth gonsalves]

On Thu, 2012-02-16 at 20:08 -0800, Matt Cotterell wrote:
> project the 'production' server running on mod_python no longer works.

mod_python is deprecated - use mod_wsgi
-- 
regards
Kenneth Gonsalves

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

"DatabaseError: can't adapt type 'NavigableString'" when using psycopg2 and Django 1.3

[Matt Cotterell]

Hi guys! New poster here and django newbie, though I'm starting to get
a handle on it now.

One issue though which is preventing release of my project is a truely
bizarre bug pertaining *purely* to postgres. I'm running Django
(1.3.1) with psycopg2 (2.2.1) and despite everything working on the
development 'runserver' server using SQLite, at some point during this
project the 'production' server running on mod_python no longer works.

The fault specifically pertains to a custom authentication module
which gets XML data over an HTTP call with pycurl. When logged in as a
regular 'ModelBackend' user, everything works fine. However when
trying to create a new User object as such:

...
except User.DoesNotExist:
# Create a new user. Note that setting the password really doesn't
mean anything.
user = User(
username=username,
email=username,
password='',
first_name=user_firstname,
last_name=user_lastname
)
user.save()
...

...I get the following Exception when calling save():

Exception Type: DatabaseError
Exception Value: can't adapt type 'NavigableString'
(traceback: http://dpaste.com/704253/)

The local variables at the time of exception are:

username:   u'matt...@example.com'
c: 
password: u'x'
user_firstname: u'Matthew'
user_lastname: u'Cotterell'
self: 
storage: 
user: 
url_string: 'https://auth.example.com:8181/ExternalAuthentication/
Login?username=matt...@example.com&password=x'

And seem to have been caused by psycopg2 here:

/usr/local/lib/python2.6/dist-packages/django/db/backends/
postgresql_psycopg2/base.py in execute

"""
def __init__(self, cursor):
self.cursor = cursor
def execute(self, query, args=None):
try:
   return self.cursor.execute(query, args) ...
except Database.IntegrityError, e:
raise utils.IntegrityError,
utils.IntegrityError(*tuple(e)), sys.exc_info()[2]
except Database.DatabaseError, e:
raise utils.DatabaseError, utils.DatabaseError(*tuple(e)),
sys.exc_info()[2]
def executemany(self, query, args):

query: 'INSERT INTO "auth_user" ("username", "first_name",
"last_name", "email", "password", "is_staff", "is_active",
"is_superuser", "last_login", "date_joined") VALUES (%s, %s, %s, %s,
%s, %s, %s, %s, %s, %s)'
self: 
args: (u'matt...@example.com',
 u'Matthew',
 u'Cotterell',
 u'matt...@example.com',
 u' ',
 False,
 True,
 False,
 u'2012-02-17 15:34:59.735209',
 u'2012-02-17 15:34:59.735222')
e: ProgrammingError("can't adapt type 'NavigableString'",)

So I know everything on my end is at least getting filled in properly.
Oddly enough, if I comment out the first_name and last_name lines, it
goes through (and causes a similar exception a few lines ahead on a
similar 'object creation' section of code. So maybe it's somethign to
do with those two lines?

It's just bizzare, I'm creating objects for other areas of the
projects perfectly fine, it's just here that it's being stubborn.
Googling the issue only highlights the fact it's likely a psycopg2
issue, but not much else.

Thanks so much to anyone who can help me here, I'm completely stumped
as to why such a simple operation can go so wrong...

Matt

-- 
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: @commit_on_success with Class based view in Django 1.3

[Yann]

but on which method of the class view?

the post method?

On Feb 16, 12:03 pm, Matt Schinckel  wrote:
> You can use the @method_decorator decorator decorator.
>
> https://docs.djangoproject.com/en/dev/topics/class-based-views/#decor...

-- 
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: @commit_on_success with Class based view in Django 1.3

[Matt Schinckel]

You can use the @method_decorator decorator decorator.

https://docs.djangoproject.com/en/dev/topics/class-based-views/#decorating-class-based-views

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/s5ShG52nRpcJ.
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: @commit_on_success with Class based view in Django 1.3

[Yann]

Thanks. But the more important question is how to use
commit_on_success with class based view?



On Feb 16, 1:52 am, 赵帅  wrote:
> The commit_on_success decorator only garrentees that one commit is done
> when no exception is raised from the function and rollback if there is any .
> You have to ensure on your own hand the values in the two tables are equal.
>
> 2012/2/15 Yann 
>
>
>
>
>
>
>
> > Hi,
>
> > In a class view, I am trying to modify two instances of different
> > models. There are some identical data stored in both tables. They
> > should really be the same in any circumstance .
>
> > Should I use "@commit_on_success"?
>
> > If I should, how should i use it for the class based view?
>
> > Should I do something like this?
>
> > class CreateSomethingView(CreateView):
>
> > ""
> > ""
> >    @method_decorator(transaction.commit_on_succes)
> >    def post(self):
> >       ""
>
> > --
> > 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.

-- 
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: @commit_on_success with Class based view in Django 1.3

[赵帅]

The commit_on_success decorator only garrentees that one commit is done
when no exception is raised from the function and rollback if there is any .
You have to ensure on your own hand the values in the two tables are equal.

2012/2/15 Yann 

> Hi,
>
> In a class view, I am trying to modify two instances of different
> models. There are some identical data stored in both tables. They
> should really be the same in any circumstance .
>
> Should I use "@commit_on_success"?
>
> If I should, how should i use it for the class based view?
>
> Should I do something like this?
>
> class CreateSomethingView(CreateView):
>
> ""
> ""
>@method_decorator(transaction.commit_on_succes)
>def post(self):
>   ""
>
>
> --
> 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.
>
>

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

@commit_on_success with Class based view in Django 1.3

[Yann]

Hi,

In a class view, I am trying to modify two instances of different
models. There are some identical data stored in both tables. They
should really be the same in any circumstance .

Should I use "@commit_on_success"?

If I should, how should i use it for the class based view?

Should I do something like this?

class CreateSomethingView(CreateView):

""
""
@method_decorator(transaction.commit_on_succes)
def post(self):
   ""


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

memcached, django 1.3: per-site caching with middleware

[trewq]

Hi Folks,

I am trying to get memcached working with django, and based on stats from 
the memcached, it is getting requests, but django is not sending it any 
thing. 

I created a question on 
stackoverflow<http://stackoverflow.com/questions/8737678/memcached-slows-down-website>and
 looks like a debugger and peering into the middleware maybe the next 
step. I wanted to find out if are aware of any issues for site-level 
caching with middleware. I upgraded memcached to 1.4.10 and am using django 
1.3.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/nW2lLrWaw1YJ.
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.

django 1.3 and django-test-utils Persistent Database Test Runner

[Gelonida N]

I just discovered django-test-utils on the web and noticed, that it has
some functionality, that looks interesting to me.

http://readthedocs.org/docs/django-test-utils/en/latest/keep_database_runner.html#
this shall introduce a management command 'quicktest', which is supposed
to keep the test database intact between two test runs.

However the documentation dates from 2009 and contains the comment:
> Currently support for 1.2 is in a 1.2 compatible branch. This will be merged 
> into trunk soon.

which might indicate, that the project is no more maintained and not
usable for django_1.3

A first test indicates also, that the code is not compatible with django
1.3 (import errors)

Now my question:

Is there an alternative module or is there even a new default
django 1.3 feature allowing to keep a database between two test runs?
avoiding the creation of a db (with all south migrations being applied)


Thanks in advance for suggestions.



-- 
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: Nested formsets at Django 1.3

[Ilya]

The validation error happens when the formset is passed an empty 
dictionary. The docs (release notes for 1.3) suggest passing None instead. 
So doing this should fix the problem:
>
> TenantFormset(data=self.data or None, instance=instance, 
prefix='TENANTS_%s' % pk_value)

In my case, which is similar to Nathan's, this made the validation error to 
go away.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/ZHnO7qM0OJoJ.
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: django 1.3: how to use pagination with class based views?

[Andriyko]

Ok. page_obj is what I need.

On Oct 17, 10:34 pm, Andriyko  wrote:
> Hello,
>
> I have following view in views.py:
> .
> class  ArticleArchiveIndexView(ArticleViewAbstractClass,
> ArchiveIndexView):
>     queryset = Article.live.all()
>     date_field = 'pub_date'
>     context_object_name = 'articles_list'
>     paginate_by = ARTICLES_PER_PAGE
> ..
>
> How do I use 'paginate_by'?
> Should the Article model have Paginator instance?
> Please provide an example with template.
>
> 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.

django 1.3: how to use pagination with class based views?

[Andriyko]

Hello,

I have following view in views.py:
.
class  ArticleArchiveIndexView(ArticleViewAbstractClass,
ArchiveIndexView):
queryset = Article.live.all()
date_field = 'pub_date'
context_object_name = 'articles_list'
paginate_by = ARTICLES_PER_PAGE
..

How do I use 'paginate_by'?
Should the Article model have Paginator instance?
Please provide an example with template.

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.

Re: django 1.3: how to use get_abolute_url in class based generic views

[Reinout van Rees]

On 13-10-11 23:57, Andriyko wrote:


class Article(models.Model):
 ..
# with django 1.2 was
@models.permalink
 def get_absolute_url(self):
 return ('article_detail', (), {  'year':
self.pub_date.strftime("%Y"),
  'month':
self.pub_date.strftime("%m").lower(),
  'day':
self.pub_date.strftime("%d"),
          'slug': self.slug })
# how should it look with django 1.3 ??


Your get_absolute_url() returns a tuple instead of a url.
You forgot to call reverse():

from django.core.urlresolvers import reverse

...
def get_absolute_url(self):
return reverse('article_detail', (), {  'year':
   ^^^
...

That's probably it.


Reinout - class based views are great - van Rees

--
Reinout van Reeshttp://reinout.vanrees.org/
rein...@vanrees.org http://www.nelen-schuurmans.nl/
"If you're not sure what to do, make something. -- Paul Graham"

--
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: django 1.3: how to use get_abolute_url in class based generic views

[Andriyko]

Thank you for reply, but I still get the errror
Template error

In template .../weblog/templates/blog/article_archive.html, error at
line 6

Caught ViewDoesNotExist while rendering: Tried archive_day in module
django.views.generic.dates. Error was: 'module' object has no
attribute 'archive_day'
1   {% extends "blog/index.html" %}
2
3   {% block column1 %}
4   Archive
5   
6   {% for article in object_list %}
7   {{ article.title }}

8   Posted by {{ article.author }} on {{ article.pub_date|date:"F
jS,
Y" }}
9   
10  {% endfor %}
11  
12  {% endblock %}
13  {% block column2 %}Last article here{% endblock %}

Could you please give an example about how to use get_absolute_url
with class based generic views?

On Oct 14, 1:31 pm, Fabrizio Mancini  wrote:
> On 13 October 2011 23:57, Andriyko  wrote:
>
> > urlpatterns = patterns('django.views.generic.dates',
> > (r'^(?P\d{4})/v/(?P\d{2})/(?P[-\w]+)/
> > $', DateDetailView.as_view(template_name='blog/article_detail.html',
> > **entry_info_dict)),
> > )
>
> Hi,
> You are using
> (?P\w{3})
> but in get_absolute_url you are using
> self.pub_date.strftime("%m").lower(),
> referring tohttp://docs.python.org/library/time.html#time.strftime
> %m return Month as a decimal number [01,12].
> this won't never work
> You should use %b instead of %m
> This should work
> HTH
> Fabrizio
>
>
>
>
>
>
>
> > = models.py 
>
> > class Article(models.Model):
> >    ..
> >   # with django 1.2 was
> >       @models.permalink
> >    def get_absolute_url(self):
> >        return ('article_detail', (), {  'year':
> > self.pub_date.strftime("%Y"),
> >                                         'month':
> > self.pub_date.strftime("%m").lower(),
> >                                         'day':
> > self.pub_date.strftime("%d"),
> >                                         'slug': self.slug })
> >   # how should it look with django 1.3 ??

-- 
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: django 1.3: how to use get_abolute_url in class based generic views

[Andriyko]

Thank you for reply, but I still get the errror
Template error

In template /home/pinglin/DjangoProjects/weblog/templates/blog/
article_archive.html, error at line 6

Caught ViewDoesNotExist while rendering: Tried archive_day in module
django.views.generic.dates. Error was: 'module' object has no
attribute 'archive_day'
1   {% extends "blog/index.html" %}
2
3   {% block column1 %}
4   Archive
5   
6   {% for article in object_list %}
7   {{ article.title }}

8   Posted by {{ article.author }} on {{ article.pub_date|date:"F jS,
Y" }}
9   
10  {% endfor %}
11  
12  {% endblock %}
13  {% block column2 %}Last article here{% endblock %}

Could you please give an example about how to use get_absolute_url
with class based generic views?

On Oct 14, 1:31 pm, Fabrizio Mancini  wrote:
> On 13 October 2011 23:57, Andriyko  wrote:
>
> > urlpatterns = patterns('django.views.generic.dates',
> > (r'^(?P\d{4})/v/(?P\d{2})/(?P[-\w]+)/
> > $', DateDetailView.as_view(template_name='blog/article_detail.html',
> > **entry_info_dict)),
> > )
>
> Hi,
> You are using
> (?P\w{3})
> but in get_absolute_url you are using
> self.pub_date.strftime("%m").lower(),
> referring tohttp://docs.python.org/library/time.html#time.strftime
> %m return Month as a decimal number [01,12].
> this won't never work
> You should use %b instead of %m
> This should work
> HTH
> Fabrizio
>
>
>
>
>
>
>
> > = models.py 
>
> > class Article(models.Model):
> >    ..
> >   # with django 1.2 was
> >       @models.permalink
> >    def get_absolute_url(self):
> >        return ('article_detail', (), {  'year':
> > self.pub_date.strftime("%Y"),
> >                                         'month':
> > self.pub_date.strftime("%m").lower(),
> >                                         'day':
> > self.pub_date.strftime("%d"),
> >                                         'slug': self.slug })
> >   # how should it look with django 1.3 ??

-- 
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: django 1.3: how to use get_abolute_url in class based generic views

[Fabrizio Mancini]

On 13 October 2011 23:57, Andriyko  wrote:

> urlpatterns = patterns('django.views.generic.dates',
> (r'^(?P\d{4})/v/(?P\d{2})/(?P[-\w]+)/
> $', DateDetailView.as_view(template_name='blog/article_detail.html',
> **entry_info_dict)),
> )
>
Hi,
You are using
(?P\w{3})
but in get_absolute_url you are using
self.pub_date.strftime("%m").lower(),
referring to http://docs.python.org/library/time.html#time.strftime
%m return Month as a decimal number [01,12].
this won't never work
You should use %b instead of %m
This should work
HTH
Fabrizio



> = models.py 
>
> class Article(models.Model):
>..
>   # with django 1.2 was
>   @models.permalink
>def get_absolute_url(self):
>return ('article_detail', (), {  'year':
> self.pub_date.strftime("%Y"),
> 'month':
> self.pub_date.strftime("%m").lower(),
>         'day':
> self.pub_date.strftime("%d"),
> 'slug': self.slug })
>   # how should it look with django 1.3 ??
>
>
>

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

django 1.3: how to use get_abolute_url in class based generic views

[Andriyko]

I have following:
= urls.py 
from django.conf.urls.defaults import *
from django.views.generic.dates import DateDetailView

from blog.models import Article

entry_info_dict = {
'queryset': Article.objects.all(),
'date_field': 'pub_date',
}

urlpatterns = patterns('django.views.generic.dates',
(r'^(?P\d{4})/(?P\w{3})/(?P\d{2})/(?P[-\w]+)/
$', DateDetailView.as_view(template_name='blog/article_detail.html',
**entry_info_dict)),
)

= models.py 

class Article(models.Model):
..
   # with django 1.2 was
   @models.permalink
def get_absolute_url(self):
return ('article_detail', (), {  'year':
self.pub_date.strftime("%Y"),
 'month':
self.pub_date.strftime("%m").lower(),
 'day':
self.pub_date.strftime("%d"),
 'slug': self.slug })
   # how should it look with django 1.3 ??


And this does not work in template


{% for article in object_list %} # ???
{{ article.title }}
# 
Posted by {{ article.author }} on {{ article.pub_date|
date:"F jS, Y" }}

{% endfor %}


Please give an example of how to use get_absolute_url within class
based generic views.

-- 
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: [Django 1.3] django.views.generic.TemplateView example

[Micky Hulse]

Ack! Russ, I missed this e-mail! I am so sorry for the late reply!

Thanks so much for helping me out, I really appreciate it. :)

On Fri, Sep 30, 2011 at 9:08 PM, Russell Keith-Magee
 wrote:
> There's no need to subclass TemplateView and provide your own implementation
> of get_context_data() - the default TemplateView implementation does exactly
> (and I mean character-for-character exactly) what you've defined. So, you
> just need to deploy a default TemplateView in your urls.py:

Hehe! Thanks so much for pointing that out! I should have visited the
source code before posting my question. :(

It's funny, I was just going to reply to the list with my latest
solution... Long story short, my co-worker shared this code:

urlpatterns = patterns('',
   (r'^phone-list/$', ListView.as_view(
   queryset=Staffer.objects.filter(active=True).order_by('last_name'),
   )),
)

... and that motivated me to read the source code [1] and write this
in my urls.py:

from django.views import generic
...
(r'^(?P[a-zA-Z0-9]{32})/$', generic.TemplateView.as_view(
template_name='wire/feed.html',
)),
...

Exactly what you suggested that I do!

That's great though. Thank you for taking the time to help me out, I
really appreciate it. :)

> I know the class-based views docs aren't as good as they could be - thats
> mostly my fault. I also know that "read the source" isn't a real
> documentation answer. However, the CBV code is quite well documented
> internally, and isn't all that complex at the end of the day - if you've got
> questions about how to do something obscure with CBVs, a quick peruse of the
> source is well worth your time.

That works for me! Like I said above, I should have read the source
code before bugging the group. It's amazing how clear things can be
when reading the Django source code.

>From now on, I will be sure to go to the code before asking questions. :D

Thanks again! Have an awesome day.

[1] 
https://code.djangoproject.com/browser/django/trunk/django/views/generic/base.py#L114

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

Django 1.3 logging, how to log INFO to file1.log and ERROR to file2.log

[robinne]

I want to log ERRORs to an error log and INFO to an info log file. I
have it setup like this, but the info log files gets both INFO and
ERROR logging (because it allows INFO and above severity). How do I
only run a handler for INFO and not higher items such as ERROR.

LOGGING = {
'version': 1,
'disable_existing_loggers': True,
'formatters': {
'verbose': {
'format': '%(levelname)s %(asctime)s %(module)s %
(process)d %(thread)d %(message)s'
},
'simple': {
'format': '%(levelname)s %(message)s'
},
},
'handlers': {
'null': {
'level':'DEBUG',
'class':'django.utils.log.NullHandler',
},
'console':{
'level':'DEBUG',
'class':'logging.StreamHandler',
'formatter': 'simple'
},
'mail_admins': {
'level': 'ERROR',
'class': 'django.utils.log.AdminEmailHandler',
},
'log_errors':{
'level':'ERROR',
'class' : 'logging.handlers.RotatingFileHandler',
'filename' : os.path.join(SITEROOT, 'Logs/errors.log'),
'formatter' : 'verbose',
'backupCount' :'5',
'maxBytes' : '500'
},
'log_info':{
'level':'INFO',
'class' : 'logging.handlers.RotatingFileHandler',
'filename' : os.path.join(SITEROOT, 'Logs/info.log'),
'formatter' : 'simple',
'backupCount' :'5',
'maxBytes' : '500'
}
},
'loggers': {
'django': {
'handlers':['null'],
'propagate': True,
'level':'INFO',
},
'django.request': {
'handlers': ['log_errors'],
'level': 'ERROR',
'propagate': False,
},
'':{
'handlers': ['log_errors', 'log_info'],
'level': 'INFO',
'propagate': False,
}

}
}

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

Django 1.3 logging, django.request logger not processed

[robinne]

I have setup my application to use the settings from the django
documentation on logging, with a few items removed for simplicity. I
have found that the logger django.request is not running even though I
am trying to log an error from within a view. If I add  '' logger
(thanks to some other posts found here), that logger will run a
handler. What am I missing with the default django.request logger?

#settings
LOGGING = {
'version': 1,
'disable_existing_loggers': True,
'formatters': {
'verbose': {
'format': '%(levelname)s %(asctime)s %(module)s %
(process)d %(thread)d %(message)s'
},
'simple': {
'format': '%(levelname)s %(message)s'
},
},
'handlers': {
'null': {
'level':'DEBUG',
'class':'django.utils.log.NullHandler',
},
'console':{
'level':'DEBUG',
'class':'logging.StreamHandler',
'formatter': 'simple'
},
'mail_admins': {
'level': 'ERROR',
'class': 'django.utils.log.AdminEmailHandler',
},
'log_it':{
'level':'ERROR',
'class' : 'logging.handlers.RotatingFileHandler',
'filename' : os.path.join(SITEROOT, 'MYLOGGING.log'),
'formatter' : 'verbose',
'backupCount' :'5',
'maxBytes' : '500'
}
},
'loggers': {
'django': {
'handlers':['null'],
'propagate': True,
'level':'INFO',
},
'django.request': {
'handlers': ['log_it'],
'level': 'ERROR',
'propagate': False,
},
'':{
'handlers': ['log_it'],
'level': 'ERROR',
'propagate': False,
}


}
}


and the view...

import logging
logger = logging.getLogger(__name__)

def FAQ(request):
logger.error('test logging error')
return render_to_response("FAQ.html",
context_instance=RequestContext(request))


-- 
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: django 1.3 upgrade problem

[Xavier Ordoquy]

Hi,

I'm a bit curious about the ModPythonRequest object which makes me think you 
are using mod_python.
If this is the case, you should note that its support is deprecated:

Support for mod_python has been deprecated, and will be removed in Django 1.5. 
If you are configuring a new deployment, you are strongly encouraged to 
consider using mod_wsgi or any of the other supported backends.


Regards,
Xavier.

Le 2 oct. 2011 à 16:52, shiva a écrit :

> I recently updgraded to django 1.3. After the upgrade, I get the
> following error whenever I used request.POST:
> 
> Traceback (most recent call last):
> 
> File "/usr/lib/python2.4/site-packages/django/core/handlers/base.py",
> line 86, in  get_response
> response = None
> 
> File "/public/gdp/trunk/src/ukl/lis/process/utils/error_handler.py",
> line 15, in __call__
> return self.function(*args, **kwargs)
> 
> File "/usr/lib/python2.4/site-packages/django/views/decorators/
> cache.py", line 30, in _cache_controlled
> # and this:
> 
> File "/public/gdp/trunk/src/ukl/lis/process/authentication/views.py",
> line 438, in login
> form = loginForm(request.POST)
> 
> File "/usr/lib/python2.4/site-packages/django/core/handlers/
> modpython.py", line 101, in _get_post
> self._load_post_and_files()
> 
> AttributeError: 'ModPythonRequest' object has no attribute
> '_load_post_and_files'
> 
> -- 
> 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.
> 

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

django 1.3 upgrade problem

[shiva]

I recently updgraded to django 1.3. After the upgrade, I get the
following error whenever I used request.POST:

Traceback (most recent call last):

File "/usr/lib/python2.4/site-packages/django/core/handlers/base.py",
line 86, in  get_response
response = None

File "/public/gdp/trunk/src/ukl/lis/process/utils/error_handler.py",
line 15, in __call__
return self.function(*args, **kwargs)

File "/usr/lib/python2.4/site-packages/django/views/decorators/
cache.py", line 30, in _cache_controlled
# and this:

File "/public/gdp/trunk/src/ukl/lis/process/authentication/views.py",
line 438, in login
form = loginForm(request.POST)

File "/usr/lib/python2.4/site-packages/django/core/handlers/
modpython.py", line 101, in _get_post
self._load_post_and_files()

AttributeError: 'ModPythonRequest' object has no attribute
'_load_post_and_files'

-- 
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: [Django 1.3] django.views.generic.TemplateView example

[Russell Keith-Magee]

On Saturday, October 1, 2011, Micky Hulse  wrote:
> Code:
>
> 
>
> When using the new class-based generic views, is there a faster way
> for me to pass URL params to the template?

There's no need to subclass TemplateView and provide your own implementation
of get_context_data() - the default TemplateView implementation does exactly
(and I mean character-for-character exactly) what you've defined. So, you
just need to deploy a default TemplateView in your urls.py:

('^foo/(?P\d+)/$',
TemplateView.as_view(template_name='my_template.html'))

Your template should work exactly as-is.

I know the class-based views docs aren't as good as they could be - thats
mostly my fault. I also know that "read the source" isn't a real
documentation answer. However, the CBV code is quite well documented
internally, and isn't all that complex at the end of the day - if you've got
questions about how to do something obscure with CBVs, a quick peruse of the
source is well worth your time.

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

[Django 1.3] django.views.generic.TemplateView example

[Micky Hulse]

Code:



When using the new class-based generic views, is there a faster way
for me to pass URL params to the template?

Thanks!
Micky

-- 
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: FieldError on ManyToMany after upgrading to Django 1.3

[Philip Mountifield]

So I've had a further look into this.

Firstly, I updated to PG 8.4, and found the the issue is still there. 
Secondly I had a look at Matthias' code on github and tries a few hacks. 
I found that clearing the caches on the opposite side of the many to 
many relationship solved the problem.


E.g. for "an_instance.a_many_to_many_field" I cleared the caches in 
"an_instance.a_many_to_many_field.model._meta"


Now I'm going to look into the creation of the dynamic models to see 
what has changed between Django 1.2 and 1.3 in how this happens and 
their sequence.


Philip

On 26/09/2011 11:37, Matthias Kestenholz wrote:

On Mon, Sep 26, 2011 at 12:36 PM, Matthias Kestenholz  wrote:

On Mon, Sep 26, 2011 at 12:34 PM, Philip Mountifield
  wrote:

I also have a great deal of dynamically generated models. Interestingly in
my case I find the issue when using the development server with DEBUG =
TRUE, I've not yet tried it in deployment.

I'll take a look at your github, thanks for sharing the link.

Out of interest, with respect to David's comment about postgres versions, do
you use version 8.1 or another?


(Sorry for pressing send too early.)


We don't use postgresql at all (unfortunately, but that's a different
topic) on the site in question.


Matthias


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

Wrong view prefix on Django 1.3, mod_wsgi and mutliple URLconfs

[lucamag]

Hi all,
I'm using multiple URLconfs for my simple django application.
Everything works fine in development mode, but I'm getting a strange
error when moving to Apache 2 with mod_wsgi.

My main urls.py looks like:

---
from django.conf.urls.defaults import *
from django.conf import settings

# Uncomment the next two lines to enable the admin:
from django.contrib import admin
admin.autodiscover()

urlpatterns = patterns('',
# Include app URL structure
(r'^alerts/', include('mymodule.urls')),
# Uncomment the admin/doc line below to enable admin
documentation:
(r'^admin/doc/', include('django.contrib.admindocs.urls')),
# Uncomment the next line to enable the admin:
(r'^admin/', include(admin.site.urls)),
)
---

and the urls.py for my first module is below.
Please note I'm using a prefix view:

---
from django.conf.urls.defaults import *
urlpatterns = patterns('assistant.views',
# Example:
(r'^view/(?P\d+)/$', 'detail'),
(r'^$', 'index'),
)
---

How can it be that the once running in Apache my main application
works fine, but the admin page fails with a "TemplateSyntaxError"
because it tries to use a wrong view name,  It looks for
"assistant.views.django.view.generic.simple" rather then
"django.views.generic.simple"?

The problem disappear if merging everything in one urls.py file
without any view prefix.

Thanks in advance!
Luca

-- 
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: FieldError on ManyToMany after upgrading to Django 1.3

[Matthias Kestenholz]

On Mon, Sep 26, 2011 at 12:36 PM, Matthias Kestenholz  wrote:
> On Mon, Sep 26, 2011 at 12:34 PM, Philip Mountifield
>  wrote:
>> I also have a great deal of dynamically generated models. Interestingly in
>> my case I find the issue when using the development server with DEBUG =
>> TRUE, I've not yet tried it in deployment.
>>
>> I'll take a look at your github, thanks for sharing the link.
>>
>> Out of interest, with respect to David's comment about postgres versions, do
>> you use version 8.1 or another?
>>

(Sorry for pressing send too early.)


We don't use postgresql at all (unfortunately, but that's a different
topic) on the site in question.


Matthias

-- 
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: FieldError on ManyToMany after upgrading to Django 1.3

[Matthias Kestenholz]

On Mon, Sep 26, 2011 at 12:34 PM, Philip Mountifield
 wrote:
> I also have a great deal of dynamically generated models. Interestingly in
> my case I find the issue when using the development server with DEBUG =
> TRUE, I've not yet tried it in deployment.
>
> I'll take a look at your github, thanks for sharing the link.
>
> Out of interest, with respect to David's comment about postgres versions, do
> you use version 8.1 or another?
>

We don't (unfortunately, but that's a different topic) on the site in question.


Matthias

-- 
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: FieldError on ManyToMany after upgrading to Django 1.3

[David Markey]

I actually haven't moved.. I'm still using django 1.2.x. :)

Although we plan to move to PG 9.1 and django 1.3 within the next few
weeks(we are already using both in testing)

I think i read something somewhere in the django 1.3 documentation that PG
8.1 was not supported any more(could have dreamt it though).





On 26 September 2011 11:30, Philip Mountifield wrote:

>  I am indeed using psycopyg2 and pg8.1, which version did you move to in
> order to solve the problem? I have just been using 8.1 since it was the
> default for CentOS 5, but I also see the 8.4 is available via yum.
>
> Philip
>
>
> On 26/09/2011 11:20, David Markey wrote:
>
> I had some problems with 1.3 and Postgres 8.1,
>
>  Are you using psycopg2 and pg 8.1?
>
> On 26 September 2011 11:16, Russell Keith-Magee 
> wrote:
>
>> Hi Philip,
>>
>> I can't say I've seen the error you report.
>>
>> My immediate question when I see reports like this is "what else are
>> you doing?". Django has an extensive test suite, and things like m2m
>> fields are tested very heavily. Outside of Django's test suite, there
>> are thousands of applications out there using Django, and many of them
>> are using Django 1.3, and this is the first time that this particular
>> problem has been reported. So, you are clearly doing *something* that
>> is unusual (whether you know it's unusual or not).
>>
>> What we need is a reproducible test case -- the smallest possible
>> sample of code that works under 1.2.7, but breaks under 1.3.1. That
>> will provide us the basis on which to debug the problem, and form the
>> core of a regression test to make sure the problem doesn't occur again
>> in the future.
>>
>> Yours,
>> Russ Magee %-)
>>
>> On Mon, Sep 26, 2011 at 4:27 PM, Philip Mountifield
>>  wrote:
>> > Has anyone else experienced this error? Any help would be appreciated.
>> >
>> > Thanks
>> >
>> > Philip
>> >
>> > On 23/09/2011 14:40, Philip wrote:
>> >>
>> >> Just been updating to Django 1.3.1 and come across an odd error. I'm
>> >> getting the following error from some code which works with version
>> >> 1.2.7.
>> >>
>> >> FieldError: Cannot resolve keyword 'email_config_set' into field.
>> >> Choices are: id, name, site, type
>> >>
>> >> The odd thing being email_config_set is a related name for a
>> >> ManyToMany field. I'm not sure why django is trying to resolve it into
>> >> a field.
>> >>
>> >> To make it even more odd, this error occurs when DEBUG = TRUE and not
>> >> when DEBUG = FALSE when testing with runserver.
>> >>
>> >> I've been trying to solve this for days now with much googling/pdb/
>> >> logging, but since the exception originates deep inside django I'm not
>> >> familiar enough to find what is going wrong:
>> >>
>> >> Traceback (most recent call last):
>> >>   File "./core/driver.py", line 268, in run
>> >> self.init_norm()
>> >>   File "./driver/emailevent/background.py", line 130, in init_norm
>> >> self.load_config()
>> >>   File "./driver/emailevent/background.py", line 71, in load_config
>> >> events = list(config.events.select_related())
>> >>   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> >> django/db/models/manager.py", line 168, in select_related
>> >> return self.get_query_set().select_related(*args, **kwargs)
>> >>   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> >> django/db/models/fields/related.py", line 497, in get_query_set
>> >> return
>> >>
>> >>
>> superclass.get_query_set(self).using(db)._next_is_sticky().filter(**(self.core_filters))
>> >>   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> >> django/db/models/query.py", line 550, in filter
>> >> return self._filter_or_exclude(False, *args, **kwargs)
>> >>   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> >> django/db/models/query.py", line 568, in _filter_or_exclude
>> >> clone.query.add_q(Q(*args, **kwargs))
>> >>   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> >> django/db/models/sql/query.py", line 1194, in

Re: FieldError on ManyToMany after upgrading to Django 1.3

[Philip Mountifield]

I also have a great deal of dynamically generated models. Interestingly 
in my case I find the issue when using the development server with DEBUG 
= TRUE, I've not yet tried it in deployment.


I'll take a look at your github, thanks for sharing the link.

Out of interest, with respect to David's comment about postgres 
versions, do you use version 8.1 or another?


Phil

On 26/09/2011 11:27, Matthias Kestenholz wrote:

Hi Philip

On Fri, Sep 23, 2011 at 3:40 PM, Philip  wrote:

FieldError: Cannot resolve keyword 'email_config_set' into field.
Choices are: id, name, site, type

Any ideas/solutions/pointers/tips would be most welcome.

Yes, I've seen similar problems in two sites I'm running. I suspect it
has to do with dynamically created models and startup timing effects
in our case. I'm not sure when it started and it's really hard to test
because it only happens in production (mod_wsgi / DEBUG=False) and I
don't have a consistent view of when the problem happens yet.

What we are doing in FeinCMS against it is trying to remove the caches
on Model._meta when new models are being created; this works for us,
but isn't all that nice. I'm running the following code in production
and will be waiting a few hours / days for the problem to manifest
itself again, hoping it wont:
https://github.com/matthiask/feincms/commit/f2de708a09f8b6cf4fdbca6b3583747b6ebbc2e2


Matthias




--

Philip Mountifield
Formac Electronics Ltd
tel  +44 (0) 1225 837333
fax  +44 (0) 1225 430995

pmountifi...@formac.net
www.formac.net
www.telgas.net

--
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: FieldError on ManyToMany after upgrading to Django 1.3

[Philip Mountifield]

I am indeed using psycopyg2 and pg8.1, which version did you move to in 
order to solve the problem? I have just been using 8.1 since it was the 
default for CentOS 5, but I also see the 8.4 is available via yum.


Philip

On 26/09/2011 11:20, David Markey wrote:

I had some problems with 1.3 and Postgres 8.1,

Are you using psycopg2 and pg 8.1?

On 26 September 2011 11:16, Russell Keith-Magee 
mailto:russ...@keith-magee.com>> wrote:


Hi Philip,

I can't say I've seen the error you report.

My immediate question when I see reports like this is "what else are
you doing?". Django has an extensive test suite, and things like m2m
fields are tested very heavily. Outside of Django's test suite, there
are thousands of applications out there using Django, and many of them
are using Django 1.3, and this is the first time that this particular
problem has been reported. So, you are clearly doing *something* that
is unusual (whether you know it's unusual or not).

What we need is a reproducible test case -- the smallest possible
sample of code that works under 1.2.7, but breaks under 1.3.1. That
will provide us the basis on which to debug the problem, and form the
core of a regression test to make sure the problem doesn't occur again
in the future.

Yours,
Russ Magee %-)

On Mon, Sep 26, 2011 at 4:27 PM, Philip Mountifield
mailto:pmountifi...@formac.net>> wrote:
> Has anyone else experienced this error? Any help would be
appreciated.
>
> Thanks
>
> Philip
>
> On 23/09/2011 14:40, Philip wrote:
>>
>> Just been updating to Django 1.3.1 and come across an odd
error. I'm
>> getting the following error from some code which works with version
>> 1.2.7.
>>
>> FieldError: Cannot resolve keyword 'email_config_set' into field.
>> Choices are: id, name, site, type
>>
>> The odd thing being email_config_set is a related name for a
>> ManyToMany field. I'm not sure why django is trying to resolve
it into
>> a field.
>>
>> To make it even more odd, this error occurs when DEBUG = TRUE
and not
>> when DEBUG = FALSE when testing with runserver.
>>
>> I've been trying to solve this for days now with much googling/pdb/
>> logging, but since the exception originates deep inside django
I'm not
>> familiar enough to find what is going wrong:
>>
>> Traceback (most recent call last):
>>   File "./core/driver.py", line 268, in run
>> self.init_norm()
>>   File "./driver/emailevent/background.py", line 130, in init_norm
>> self.load_config()
>>   File "./driver/emailevent/background.py", line 71, in load_config
>> events = list(config.events.select_related())
>>   File
"/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> django/db/models/manager.py", line 168, in select_related
>> return self.get_query_set().select_related(*args, **kwargs)
>>   File
"/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> django/db/models/fields/related.py", line 497, in get_query_set
>> return
>>
>>

superclass.get_query_set(self).using(db)._next_is_sticky().filter(**(self.core_filters))
>>   File
"/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> django/db/models/query.py", line 550, in filter
>> return self._filter_or_exclude(False, *args, **kwargs)
>>   File
"/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> django/db/models/query.py", line 568, in _filter_or_exclude
>> clone.query.add_q(Q(*args, **kwargs))
>>   File
"/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> django/db/models/sql/query.py", line 1194, in add_q
>> can_reuse=used_aliases, force_having=force_having)
>>   File
"/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> django/db/models/sql/query.py", line 1069, in add_filter
>> negate=negate, process_extras=process_extras)
>>   File
"/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> django/db/models/sql/query.py", line 1260, in setup_joins
>> "Choices are: %s" % (name, ", ".join(names)))
>> FieldError: Cannot resolve keyword 'email_config_set' into field.
>> Choices are: id, name, site, type
>>
>> Any ideas

Re: FieldError on ManyToMany after upgrading to Django 1.3

[Matthias Kestenholz]

Hi Philip

On Fri, Sep 23, 2011 at 3:40 PM, Philip  wrote:
> FieldError: Cannot resolve keyword 'email_config_set' into field.
> Choices are: id, name, site, type
>
> Any ideas/solutions/pointers/tips would be most welcome.

Yes, I've seen similar problems in two sites I'm running. I suspect it
has to do with dynamically created models and startup timing effects
in our case. I'm not sure when it started and it's really hard to test
because it only happens in production (mod_wsgi / DEBUG=False) and I
don't have a consistent view of when the problem happens yet.

What we are doing in FeinCMS against it is trying to remove the caches
on Model._meta when new models are being created; this works for us,
but isn't all that nice. I'm running the following code in production
and will be waiting a few hours / days for the problem to manifest
itself again, hoping it wont:
https://github.com/matthiask/feincms/commit/f2de708a09f8b6cf4fdbca6b3583747b6ebbc2e2


Matthias

-- 
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: FieldError on ManyToMany after upgrading to Django 1.3

[David Markey]

I had some problems with 1.3 and Postgres 8.1,

Are you using psycopg2 and pg 8.1?

On 26 September 2011 11:16, Russell Keith-Magee wrote:

> Hi Philip,
>
> I can't say I've seen the error you report.
>
> My immediate question when I see reports like this is "what else are
> you doing?". Django has an extensive test suite, and things like m2m
> fields are tested very heavily. Outside of Django's test suite, there
> are thousands of applications out there using Django, and many of them
> are using Django 1.3, and this is the first time that this particular
> problem has been reported. So, you are clearly doing *something* that
> is unusual (whether you know it's unusual or not).
>
> What we need is a reproducible test case -- the smallest possible
> sample of code that works under 1.2.7, but breaks under 1.3.1. That
> will provide us the basis on which to debug the problem, and form the
> core of a regression test to make sure the problem doesn't occur again
> in the future.
>
> Yours,
> Russ Magee %-)
>
> On Mon, Sep 26, 2011 at 4:27 PM, Philip Mountifield
>  wrote:
> > Has anyone else experienced this error? Any help would be appreciated.
> >
> > Thanks
> >
> > Philip
> >
> > On 23/09/2011 14:40, Philip wrote:
> >>
> >> Just been updating to Django 1.3.1 and come across an odd error. I'm
> >> getting the following error from some code which works with version
> >> 1.2.7.
> >>
> >> FieldError: Cannot resolve keyword 'email_config_set' into field.
> >> Choices are: id, name, site, type
> >>
> >> The odd thing being email_config_set is a related name for a
> >> ManyToMany field. I'm not sure why django is trying to resolve it into
> >> a field.
> >>
> >> To make it even more odd, this error occurs when DEBUG = TRUE and not
> >> when DEBUG = FALSE when testing with runserver.
> >>
> >> I've been trying to solve this for days now with much googling/pdb/
> >> logging, but since the exception originates deep inside django I'm not
> >> familiar enough to find what is going wrong:
> >>
> >> Traceback (most recent call last):
> >>   File "./core/driver.py", line 268, in run
> >> self.init_norm()
> >>   File "./driver/emailevent/background.py", line 130, in init_norm
> >> self.load_config()
> >>   File "./driver/emailevent/background.py", line 71, in load_config
> >> events = list(config.events.select_related())
> >>   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
> >> django/db/models/manager.py", line 168, in select_related
> >> return self.get_query_set().select_related(*args, **kwargs)
> >>   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
> >> django/db/models/fields/related.py", line 497, in get_query_set
> >> return
> >>
> >>
> superclass.get_query_set(self).using(db)._next_is_sticky().filter(**(self.core_filters))
> >>   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
> >> django/db/models/query.py", line 550, in filter
> >> return self._filter_or_exclude(False, *args, **kwargs)
> >>   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
> >> django/db/models/query.py", line 568, in _filter_or_exclude
> >> clone.query.add_q(Q(*args, **kwargs))
> >>   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
> >> django/db/models/sql/query.py", line 1194, in add_q
> >> can_reuse=used_aliases, force_having=force_having)
> >>   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
> >> django/db/models/sql/query.py", line 1069, in add_filter
> >> negate=negate, process_extras=process_extras)
> >>   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
> >> django/db/models/sql/query.py", line 1260, in setup_joins
> >> "Choices are: %s" % (name, ", ".join(names)))
> >> FieldError: Cannot resolve keyword 'email_config_set' into field.
> >> Choices are: id, name, site, type
> >>
> >> Any ideas/solutions/pointers/tips would be most welcome.
> >
> > --
> > 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 unsubs

Re: FieldError on ManyToMany after upgrading to Django 1.3

[Russell Keith-Magee]

Hi Philip,

I can't say I've seen the error you report.

My immediate question when I see reports like this is "what else are
you doing?". Django has an extensive test suite, and things like m2m
fields are tested very heavily. Outside of Django's test suite, there
are thousands of applications out there using Django, and many of them
are using Django 1.3, and this is the first time that this particular
problem has been reported. So, you are clearly doing *something* that
is unusual (whether you know it's unusual or not).

What we need is a reproducible test case -- the smallest possible
sample of code that works under 1.2.7, but breaks under 1.3.1. That
will provide us the basis on which to debug the problem, and form the
core of a regression test to make sure the problem doesn't occur again
in the future.

Yours,
Russ Magee %-)

On Mon, Sep 26, 2011 at 4:27 PM, Philip Mountifield
 wrote:
> Has anyone else experienced this error? Any help would be appreciated.
>
> Thanks
>
> Philip
>
> On 23/09/2011 14:40, Philip wrote:
>>
>> Just been updating to Django 1.3.1 and come across an odd error. I'm
>> getting the following error from some code which works with version
>> 1.2.7.
>>
>> FieldError: Cannot resolve keyword 'email_config_set' into field.
>> Choices are: id, name, site, type
>>
>> The odd thing being email_config_set is a related name for a
>> ManyToMany field. I'm not sure why django is trying to resolve it into
>> a field.
>>
>> To make it even more odd, this error occurs when DEBUG = TRUE and not
>> when DEBUG = FALSE when testing with runserver.
>>
>> I've been trying to solve this for days now with much googling/pdb/
>> logging, but since the exception originates deep inside django I'm not
>> familiar enough to find what is going wrong:
>>
>> Traceback (most recent call last):
>>   File "./core/driver.py", line 268, in run
>>     self.init_norm()
>>   File "./driver/emailevent/background.py", line 130, in init_norm
>>     self.load_config()
>>   File "./driver/emailevent/background.py", line 71, in load_config
>>     events = list(config.events.select_related())
>>   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> django/db/models/manager.py", line 168, in select_related
>>     return self.get_query_set().select_related(*args, **kwargs)
>>   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> django/db/models/fields/related.py", line 497, in get_query_set
>>     return
>>
>> superclass.get_query_set(self).using(db)._next_is_sticky().filter(**(self.core_filters))
>>   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> django/db/models/query.py", line 550, in filter
>>     return self._filter_or_exclude(False, *args, **kwargs)
>>   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> django/db/models/query.py", line 568, in _filter_or_exclude
>>     clone.query.add_q(Q(*args, **kwargs))
>>   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> django/db/models/sql/query.py", line 1194, in add_q
>>     can_reuse=used_aliases, force_having=force_having)
>>   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> django/db/models/sql/query.py", line 1069, in add_filter
>>     negate=negate, process_extras=process_extras)
>>   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> django/db/models/sql/query.py", line 1260, in setup_joins
>>     "Choices are: %s" % (name, ", ".join(names)))
>> FieldError: Cannot resolve keyword 'email_config_set' into field.
>> Choices are: id, name, site, type
>>
>> Any ideas/solutions/pointers/tips would be most welcome.
>
> --
> 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.
>
>

-- 
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: FieldError on ManyToMany after upgrading to Django 1.3

[Philip Mountifield]

Has anyone else experienced this error? Any help would be appreciated.

Thanks

Philip

On 23/09/2011 14:40, Philip wrote:

Just been updating to Django 1.3.1 and come across an odd error. I'm
getting the following error from some code which works with version
1.2.7.

FieldError: Cannot resolve keyword 'email_config_set' into field.
Choices are: id, name, site, type

The odd thing being email_config_set is a related name for a
ManyToMany field. I'm not sure why django is trying to resolve it into
a field.

To make it even more odd, this error occurs when DEBUG = TRUE and not
when DEBUG = FALSE when testing with runserver.

I've been trying to solve this for days now with much googling/pdb/
logging, but since the exception originates deep inside django I'm not
familiar enough to find what is going wrong:

Traceback (most recent call last):
   File "./core/driver.py", line 268, in run
 self.init_norm()
   File "./driver/emailevent/background.py", line 130, in init_norm
 self.load_config()
   File "./driver/emailevent/background.py", line 71, in load_config
 events = list(config.events.select_related())
   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/manager.py", line 168, in select_related
 return self.get_query_set().select_related(*args, **kwargs)
   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/fields/related.py", line 497, in get_query_set
 return
superclass.get_query_set(self).using(db)._next_is_sticky().filter(**(self.core_filters))
   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/query.py", line 550, in filter
 return self._filter_or_exclude(False, *args, **kwargs)
   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/query.py", line 568, in _filter_or_exclude
 clone.query.add_q(Q(*args, **kwargs))
   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/sql/query.py", line 1194, in add_q
 can_reuse=used_aliases, force_having=force_having)
   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/sql/query.py", line 1069, in add_filter
 negate=negate, process_extras=process_extras)
   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/sql/query.py", line 1260, in setup_joins
 "Choices are: %s" % (name, ", ".join(names)))
FieldError: Cannot resolve keyword 'email_config_set' into field.
Choices are: id, name, site, type

Any ideas/solutions/pointers/tips would be most welcome.


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

FieldError on ManyToMany after upgrading to Django 1.3

[Philip]

Just been updating to Django 1.3.1 and come across an odd error. I'm
getting the following error from some code which works with version
1.2.7.

FieldError: Cannot resolve keyword 'email_config_set' into field.
Choices are: id, name, site, type

The odd thing being email_config_set is a related name for a
ManyToMany field. I'm not sure why django is trying to resolve it into
a field.

To make it even more odd, this error occurs when DEBUG = TRUE and not
when DEBUG = FALSE when testing with runserver.

I've been trying to solve this for days now with much googling/pdb/
logging, but since the exception originates deep inside django I'm not
familiar enough to find what is going wrong:

Traceback (most recent call last):
  File "./core/driver.py", line 268, in run
self.init_norm()
  File "./driver/emailevent/background.py", line 130, in init_norm
self.load_config()
  File "./driver/emailevent/background.py", line 71, in load_config
events = list(config.events.select_related())
  File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/manager.py", line 168, in select_related
return self.get_query_set().select_related(*args, **kwargs)
  File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/fields/related.py", line 497, in get_query_set
return
superclass.get_query_set(self).using(db)._next_is_sticky().filter(**(self.core_filters))
  File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/query.py", line 550, in filter
return self._filter_or_exclude(False, *args, **kwargs)
  File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/query.py", line 568, in _filter_or_exclude
clone.query.add_q(Q(*args, **kwargs))
  File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/sql/query.py", line 1194, in add_q
can_reuse=used_aliases, force_having=force_having)
  File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/sql/query.py", line 1069, in add_filter
negate=negate, process_extras=process_extras)
  File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/sql/query.py", line 1260, in setup_joins
"Choices are: %s" % (name, ", ".join(names)))
FieldError: Cannot resolve keyword 'email_config_set' into field.
Choices are: id, name, site, type

Any ideas/solutions/pointers/tips would be most welcome.

-- 
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: Class-based views or "Traditional" Views for Django 1.3?

[PFL]

Reinout van Rees has posted several articles on using Django class
based views that you might find useful  (posted Aug 23/24 2011 ):

http://reinout.vanrees.org/weblog/2011/08/24/class-based-views-walkthrough.html

-- 
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: Class-based views or "Traditional" Views for Django 1.3?

[Kurtis Mullins]

Thanks for the input from both of you! And Donald, I think I'll take you up
on that offer. I'd really like to learn them. Hopefully down the line, when
this initial project is out the door and I have solid understanding of the
CBV's, I'll be able to contribute a little to the documentation as well.

 Agreed, and fwiw both you Kurtis, and anyone else can feel free to ping me
> directly in #django if they need help getting the hang of CBV's, if i'm
> around (which I am most the day typically) I'll be more then happy to help.
>
> OTOH, getting the hang of it can be hard with the current state of the docs
> and given that they require a completely different mindset when coding
> views.
>
>  Class Based Views let you override and subclass views to modify their
> behavior, I find them to be very quick once you get the hang of them.
>
>

-- 
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: Class-based views or "Traditional" Views for Django 1.3?

[Donald Stufft]

 Agreed, and fwiw both you Kurtis, and anyone else can feel free to ping me 
directly in #django if they need help getting the hang of CBV's, if i'm around 
(which I am most the day typically) I'll be more then happy to help. 


On Wednesday, September 14, 2011 at 9:54 AM, Andre Terra wrote:

> OTOH, getting the hang of it can be hard with the current state of the docs 
> and given that they require a completely different mindset when coding views.
> 
> 
> Cheers,
> AT
> 
> On Wed, Sep 14, 2011 at 10:35 AM, Donald Stufft  (mailto:donald.stu...@gmail.com)> wrote:
> >  Class Based Views let you override and subclass views to modify their 
> > behavior, I find them to be very quick once you get the hang of them. 
> > 
> > On Wednesday, September 14, 2011 at 9:33 AM, Kurtis wrote:
> > 
> > > Hey Guys,
> > > 
> > > I'm relatively new to Django 1.3. As others have noticed, there is
> > > less documentation around the Class-Based views than typical for
> > > Django. No needs for apologies as I have seen in other threads. I
> > >  don't blame others for my lack of knowledge :)
> > > 
> > > If I am working on a large project from scratch, would it be smart to
> > > just use the traditional, function/method-based views? Or should I go
> > > ahead and try to adapt the class-based views? I am working on a
> > >  deadline so the amount of time burnt searching more in-depth for my
> > > answers could be a problem. On the other hand, if there are any
> > > advantages to using Class-based views, I may want to take advantage of
> > > them. Unfortunately, I don't know enough about the Class-based views
> > >  to really weigh that out on my own. Any information regarding this
> > > decision would be greatly appreciated.
> > > 
> > > Thanks!
> > > -Kurtis Mullins
> > > 
> > > -- 
> > > 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 
> > > (mailto:django-users@googlegroups.com).
> > > To unsubscribe from this group, send email to 
> > > django-users+unsubscr...@googlegroups.com 
> > > (mailto:django-users+unsubscr...@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 
> > (mailto:django-users@googlegroups.com).
> >  To unsubscribe from this group, send email to 
> > django-users+unsubscr...@googlegroups.com 
> > (mailto:django-users%2bunsubscr...@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 
> (mailto:django-users@googlegroups.com).
>  To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com 
> (mailto:django-users+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Class-based views or "Traditional" Views for Django 1.3?

[Andre Terra]

OTOH, getting the hang of it can be hard with the current state of the docs
and given that they require a completely different mindset when coding
views.


Cheers,
AT

On Wed, Sep 14, 2011 at 10:35 AM, Donald Stufft wrote:

>  Class Based Views let you override and subclass views to modify their
> behavior, I find them to be very quick once you get the hang of them.
>
> On Wednesday, September 14, 2011 at 9:33 AM, Kurtis wrote:
>
> Hey Guys,
>
> I'm relatively new to Django 1.3. As others have noticed, there is
> less documentation around the Class-Based views than typical for
> Django. No needs for apologies as I have seen in other threads. I
> don't blame others for my lack of knowledge :)
>
> If I am working on a large project from scratch, would it be smart to
> just use the traditional, function/method-based views? Or should I go
> ahead and try to adapt the class-based views? I am working on a
> deadline so the amount of time burnt searching more in-depth for my
> answers could be a problem. On the other hand, if there are any
> advantages to using Class-based views, I may want to take advantage of
> them. Unfortunately, I don't know enough about the Class-based views
> to really weigh that out on my own. Any information regarding this
> decision would be greatly appreciated.
>
> Thanks!
> -Kurtis Mullins
>
> --
> 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.
>
>
>  --
> 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.
>

-- 
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: Class-based views or "Traditional" Views for Django 1.3?

[Donald Stufft]

 Class Based Views let you override and subclass views to modify their 
behavior, I find them to be very quick once you get the hang of them. 


On Wednesday, September 14, 2011 at 9:33 AM, Kurtis wrote:

> Hey Guys,
> 
> I'm relatively new to Django 1.3. As others have noticed, there is
> less documentation around the Class-Based views than typical for
> Django. No needs for apologies as I have seen in other threads. I
> don't blame others for my lack of knowledge :)
> 
> If I am working on a large project from scratch, would it be smart to
> just use the traditional, function/method-based views? Or should I go
> ahead and try to adapt the class-based views? I am working on a
> deadline so the amount of time burnt searching more in-depth for my
> answers could be a problem. On the other hand, if there are any
> advantages to using Class-based views, I may want to take advantage of
> them. Unfortunately, I don't know enough about the Class-based views
> to really weigh that out on my own. Any information regarding this
> decision would be greatly appreciated.
> 
> Thanks!
> -Kurtis Mullins
> 
> -- 
> 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 
> (mailto:django-users@googlegroups.com).
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com 
> (mailto:django-users+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Class-based views or "Traditional" Views for Django 1.3?

[Kurtis]

Hey Guys,

I'm relatively new to Django 1.3. As others have noticed, there is
less documentation around the Class-Based views than typical for
Django. No needs for apologies as I have seen in other threads. I
don't blame others for my lack of knowledge :)

If I am working on a large project from scratch, would it be smart to
just use the traditional, function/method-based views? Or should I go
ahead and try to adapt the class-based views? I am working on a
deadline so the amount of time burnt searching more in-depth for my
answers could be a problem. On the other hand, if there are any
advantages to using Class-based views, I may want to take advantage of
them. Unfortunately, I don't know enough about the Class-based views
to really weigh that out on my own. Any information regarding this
decision would be greatly appreciated.

Thanks!
-Kurtis Mullins

-- 
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: Django 1.3 logging not working as I'd expect

[Alexey Luchko]

Hi,

try executing
import logging
logger = logging.getLogger('testlogger')
logger.warn('hello')
logger.info('please appear')

in ./manage shell.

--
Alex

--
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: Django 1.3 logging not working as I'd expect

[Gelonida N]

On 08/28/2011 03:43 AM, Scott Danzig wrote:
> 
> Okay.. update.. it does seem to work right, even without forcing the
> initialization as you suggested.. which is a relief.. Was losing my mind
> (maybe Django 1.3 doesn't require the settings.LOGGING?)  While testing with
> prints, I realized the view function I thought should be called wasn't
> called until AFTER login..  Oops :)
> 
> Thanks all.

Just for your info.

Forcing the import of 'settings.py' with the two lines, that I suggested
might be required in case, that your module might be
THE module using as very first module settings.py.

This is probaly NEVER the case when running in a 'normal' environment.

However for debugging I import  some of my modules from a command line
script, which just sets
sys.path and
os.environ['DJANGO_SETTINGS_MODULE']

In this case you had to force the evaluation of settings.py before
creating a logger.



> 
> 
> Gelonida N wrote:
>>
>> On 08/28/2011 12:00 AM, Scott Danzig wrote:
>>>
>>>
>>> Gelonida N wrote:
>>>> So before your three lines:
>>>>> import logging
>>>>> logger = logging.getLogger('otherlogger')
>>>>> logger.warn('hello')
>>>> you had to be sure, that the django settings and thus the logging
>>>> configuration has really been completed.
>>>>
>>>> You could for example add following two lines before:
>>>>> from django.conf import settings
>>>>> LOGGING = settings.LOGGING # force import
>>>>
>>>> The second line is needed, as the first line is a 'lazy import' and will
>>>> only read the settings and configure logging  when you access the first
>>>> time a element of settings.
>>>> I just used settings.LOGGING, as it should always exist, when you try to
>>>> log.
>>>>
>>>
>>> Thanks Gelonida.. tried your suggestion and added those two lines before
>>> my
>>> import logging ... unfortunately no change.  Perhaps it's not
>>> straightforward.  Sounds like it wasn't obvious to you either.
>>
>> That's weird.
>> This works fine for me.
>>
>>
>> Just some more things to test:
>>
>>
>> Is ee, that you didn't add a root logger in your
>> log config.
>>
>> you could add following two handlers.
>>
>>
>> 'loggers': {
>> # root loggers
>> '': {
>> 'handlers': ['console'],
>> 'level': 'WARNING', # or 'DEBUG'
>> 'propagate': True,
>> },
>> # not sure if this is really useful
>> 'root': {
>> 'handlers': ['console'],
>> 'level': 'WARNING', # or 'DEBUG'
>> 'propagate': True,
>> },
>>
>>
>>
>> If this doesn't help you could add some print statements to be sure,
>> that your settings file is really read.
>>
>>
>>
>> You could add a print statement after  the assignment of
>> LOGGING in settings.py
>>
>> LOGGING={ .. ..}
>> print "LOGGING VARIABLE IS SET NOW"
>>
>>
>>
>> and in your file.
>>
>> print "CHECKPOINT 1"
>> from django.conf import settings
>> print "CHECKPOINT 2"
>> LOGGING = settings.LOGGING # force import
>> print "CHECKPOINT 3"
>> import logging
>> logger = logging.getLogger('otherlogger')
>> print "CHECKPOINT 4"
>> logger.warn('hello')
>> print "CHECKPOINT 5"
>>
>> What do you get as output?
>>
>>
>>
>>
>> -- 
>> 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.
>>
>>
>>
> 


-- 
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: Django 1.3 logging not working as I'd expect

[Scott Danzig]

Okay.. update.. it does seem to work right, even without forcing the
initialization as you suggested.. which is a relief.. Was losing my mind
(maybe Django 1.3 doesn't require the settings.LOGGING?)  While testing with
prints, I realized the view function I thought should be called wasn't
called until AFTER login..  Oops :)

Thanks all.


Gelonida N wrote:
> 
> On 08/28/2011 12:00 AM, Scott Danzig wrote:
>> 
>> 
>> Gelonida N wrote:
>>> So before your three lines:
>>>> import logging
>>>> logger = logging.getLogger('otherlogger')
>>>> logger.warn('hello')
>>> you had to be sure, that the django settings and thus the logging
>>> configuration has really been completed.
>>>
>>> You could for example add following two lines before:
>>>> from django.conf import settings
>>>> LOGGING = settings.LOGGING # force import
>>>
>>> The second line is needed, as the first line is a 'lazy import' and will
>>> only read the settings and configure logging  when you access the first
>>> time a element of settings.
>>> I just used settings.LOGGING, as it should always exist, when you try to
>>> log.
>>>
>> 
>> Thanks Gelonida.. tried your suggestion and added those two lines before
>> my
>> import logging ... unfortunately no change.  Perhaps it's not
>> straightforward.  Sounds like it wasn't obvious to you either.
> 
> That's weird.
> This works fine for me.
> 
> 
> Just some more things to test:
> 
> 
> Is ee, that you didn't add a root logger in your
> log config.
> 
> you could add following two handlers.
> 
> 
> 'loggers': {
> # root loggers
> '': {
> 'handlers': ['console'],
> 'level': 'WARNING', # or 'DEBUG'
> 'propagate': True,
> },
> # not sure if this is really useful
> 'root': {
> 'handlers': ['console'],
> 'level': 'WARNING', # or 'DEBUG'
> 'propagate': True,
> },
> 
> 
> 
> If this doesn't help you could add some print statements to be sure,
> that your settings file is really read.
> 
> 
> 
> You could add a print statement after  the assignment of
> LOGGING in settings.py
> 
> LOGGING={ .. ..}
> print "LOGGING VARIABLE IS SET NOW"
> 
> 
> 
> and in your file.
> 
> print "CHECKPOINT 1"
> from django.conf import settings
> print "CHECKPOINT 2"
> LOGGING = settings.LOGGING # force import
> print "CHECKPOINT 3"
> import logging
> logger = logging.getLogger('otherlogger')
> print "CHECKPOINT 4"
> logger.warn('hello')
> print "CHECKPOINT 5"
> 
> What do you get as output?
> 
> 
> 
> 
> -- 
> 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.
> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Django-1.3-logging-not-working-as-I%27d-expect-tp32299898p32349771.html
Sent from the django-users mailing list archive at Nabble.com.

-- 
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: ipython 0.11 with django 1.3 /in virtualenv

[Gelonida N]

Hi Shawn,

On 08/28/2011 02:49 AM, Shawn Milochik wrote:
> If iPython is installed it should be used automatically in Django's
> manage.py shell.
> 
Apologies. I think I didn't express myself well enough.
ipython is being used bydjango.

What I just don't understand is why ipython does not import my
customisations if called via './manage.py shell'?

What I wanted to do is configuring ipython such, that it imports already
some of my application libraries when starting the shell.

This would accelerate my debugging activities.


With older versions of ipython Imanaged to do this via some code in
ipythonrc.

However since ipython 0.11 the way, that once customizes iptyhon has
changed.

Now I have to some python files like
~/.config/ipython/profile_default/ipython_config.py,
which seem to be loaded when running ipython,
but which don't seem to be loaded when running ./manage.py shell



> If it's not working and works when you run iPython directly, the most
> likely case is that you're running two different Python environments and
> one has iPython installed and the other doesn't.

I have two different ipython versions on my system:
an older one installed by my distro
and 0.11 in the same virtualenv in which I installed django.

I am rather sure though, that ./manage.py shell picks up the correct one.

If I type
dir()
in ipython, then I see the symbol 'get_ipython' which does not exist in
my old ipython version.


> 
> You mention virtualenv in the subject line but not in the question. Try
> running 'pip install ipython' in your virtualenv.
> 
> 
Yes I mentioned it in the title just in case.
I am rather sure though, that I pick up the correct ipython version



-- 
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: ipython 0.11 with django 1.3 /in virtualenv

[Shawn Milochik]

If iPython is installed it should be used automatically in Django's 
manage.py shell.


If it's not working and works when you run iPython directly, the most 
likely case is that you're running two different Python environments and 
one has iPython installed and the other doesn't.


You mention virtualenv in the subject line but not in the question. Try 
running 'pip install ipython' in your virtualenv.



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

ipython 0.11 with django 1.3 /in virtualenv

[Gelonida N]

Hi,


I am having issues with ipythin when I run

./manage.py shell
then ipython_config.py doesn't seem to be executed.

On the other hand if I run ipython directly the file is imported.

Am I missing something?


My setup:

$ find ~/.config/ipython/
/home/gelonida/.config/ipython/
/home/gelonida/.config/ipython/profile_default
/home/gelonida/.config/ipython/profile_default/log
/home/gelonida/.config/ipython/profile_default/ipython_config.py
/home/gelonida/.config/ipython/profile_default/history.sqlite
/home/gelonida/.config/ipython/profile_default/security
/home/gelonida/.config/ipython/profile_default/pid
/home/gelonida/.config/ipython/profile_default/db
/home/gelonida/.config/ipython/profile_default/db/dhist
/home/gelonida/.config/ipython/README

The contents of
/home/gelonida/.config/ipython/profile_default/ipython_config.py

The first few lines are:
import time
print (("HELLO "*17)+"\n") * 20
time.sleep(2)

I added the sleep statement in case, that the print statement woudl have
been overwritten.

If I start ipython,
then I see the HELLO text and a delay of 2 seconds happens


with

./manage.py shell

I don't see the output.

I n order to be sure, that there's nothing weird in my django project I
tested this also with an unmodified django project, which I just created
with.

In order to reproduce just run once
create a
~/.config/ipython/profile_default/ipython_config.py
with a print statement

and start
ipython
# here you should see print statements of ./manage.py shell


then do:


django-admin startproject tstipython
cd tstipython
./manage.py shell
# here you do not see print statements of ./manage.py shell

Thanks in advance for any explanations.
I would really like to understand what exactly happens.






-- 
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: Django 1.3 logging not working as I'd expect

[Gelonida N]

On 08/28/2011 12:00 AM, Scott Danzig wrote:
> 
> 
> Gelonida N wrote:
>> So before your three lines:
>>> import logging
>>> logger = logging.getLogger('otherlogger')
>>> logger.warn('hello')
>> you had to be sure, that the django settings and thus the logging
>> configuration has really been completed.
>>
>> You could for example add following two lines before:
>>> from django.conf import settings
>>> LOGGING = settings.LOGGING # force import
>>
>> The second line is needed, as the first line is a 'lazy import' and will
>> only read the settings and configure logging  when you access the first
>> time a element of settings.
>> I just used settings.LOGGING, as it should always exist, when you try to
>> log.
>>
> 
> Thanks Gelonida.. tried your suggestion and added those two lines before my
> import logging ... unfortunately no change.  Perhaps it's not
> straightforward.  Sounds like it wasn't obvious to you either.

That's weird.
This works fine for me.


Just some more things to test:


Is ee, that you didn't add a root logger in your
log config.

you could add following two handlers.


'loggers': {
# root loggers
'': {
'handlers': ['console'],
'level': 'WARNING', # or 'DEBUG'
'propagate': True,
},
# not sure if this is really useful
'root': {
'handlers': ['console'],
'level': 'WARNING', # or 'DEBUG'
'propagate': True,
},



If this doesn't help you could add some print statements to be sure,
that your settings file is really read.



You could add a print statement after  the assignment of
LOGGING in settings.py

LOGGING={ .. ..}
print "LOGGING VARIABLE IS SET NOW"



and in your file.

print "CHECKPOINT 1"
from django.conf import settings
print "CHECKPOINT 2"
LOGGING = settings.LOGGING # force import
print "CHECKPOINT 3"
import logging
logger = logging.getLogger('otherlogger')
print "CHECKPOINT 4"
logger.warn('hello')
print "CHECKPOINT 5"

What do you get as output?




-- 
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: Django 1.3 logging not working as I'd expect

[Scott Danzig]

Gelonida N wrote:
> 
> On 08/20/2011 06:51 AM, Scott Danzig wrote:
> You  have to be sure, that logging is configured before actually logging
> anything.
> 
> So before your three lines:
>> import logging
>> logger = logging.getLogger('otherlogger')
>> logger.warn('hello')
> you had to be sure, that the django settings and thus the logging
> configuration has really been completed.
> 
> You could for example add following two lines before:
>> from django.conf import settings
>> LOGGING = settings.LOGGING # force import
> 
> The second line is needed, as the first line is a 'lazy import' and will
> only read the settings and configure logging  when you access the first
> time a element of settings.
> I just used settings.LOGGING, as it should always exist, when you try to
> log.
> 

Thanks Gelonida.. tried your suggestion and added those two lines before my
import logging ... unfortunately no change.  Perhaps it's not
straightforward.  Sounds like it wasn't obvious to you either.
-- 
View this message in context: 
http://old.nabble.com/Django-1.3-logging-not-working-as-I%27d-expect-tp32299898p32349240.html
Sent from the django-users mailing list archive at Nabble.com.

-- 
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: Django 1.3 logging not working as I'd expect

[Scott Danzig]

bruno desthuilliers-7 wrote:
> 
> On 22 août, 13:27, Reinout van Rees  wrote:
>>
>> Probably all your logging statements are executed right at file import
>> time before the logging is actually configured.
> 
> Using the DictConfig in settings.py, the logger is configured before
> the apps models / views / whatever  are imported.
> 
> @Scott: Are you running the dev server ? If yes, the settings module
> should be imported "only" twice so you may import it directly (ie:
> "import settings") from your app. If yes, replace this with "from
> django.conf import settings", which is the right way to access the
> settings from an app.
> 

@Reinout: Thanks, but yeah, already tried logging from a view function..
didn't work...

@Bruno: Yeah, I am using the dev server.  I have been using from django.conf
import settings within my app to access settings..although unless I do
something like what Gelondia suggested... with the LOGGING =
settings.LOGGING, I'm not sure how the logging normally "invokes" the
settings.  The way I see it, django magically loads the settings at some
point in the background, then when you use the logging, it accesses those
settings, and there's a certain time when these settings become accessible
so this works.  But it's not working like this, so perhaps I'm mistaken.  So
you're saying to replace all instances of "from django.conf import settings"
with just "import settings"?  Or the other way around?  Not sure about what
importing only twice does, and how importing settings more or less affects
this.

Thanks all for answering.
-- 
View this message in context: 
http://old.nabble.com/Django-1.3-logging-not-working-as-I%27d-expect-tp32299898p32349226.html
Sent from the django-users mailing list archive at Nabble.com.

-- 
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: find_template Django 1.3

[demalexx]

Thank you for workaround. In my case I solved it in different way. I
know that all email templates are in db, and we use django-dbtemplates
to get them as any other template. So instead of using Django's
`find_template`, I use dbtemplate loader directly, and it returns
template source. However it's a kind of hack too, I hope Django will
allow users to get template source, I agree with you - why they want
to remove that feature.

On Aug 26, 2:42 am, Doug Ballance  wrote:
> I haven't moved to 1.3 yet, but we do a few things with the template
> source too so this is definitely of interest.  It looks like most of
> the template loaders define a load_template_source method
> implementation that does return the source, except for the cached
> loader.  As a work around you could add a module with your own
> find_template_source() method based on the existing, but calling the
> load_template_source() method instead:

-- 
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: find_template Django 1.3

[Doug Ballance]

I haven't moved to 1.3 yet, but we do a few things with the template
source too so this is definitely of interest.  It looks like most of
the template loaders define a load_template_source method
implementation that does return the source, except for the cached
loader.  As a work around you could add a module with your own
find_template_source() method based on the existing, but calling the
load_template_source() method instead:

from django.template.loader import
template_source_loaders,find_template_loader,make_origin,TemplateDoesNotExist
from django.conf import settings

def find_template_source(name, dirs=None):
global template_source_loaders
if template_source_loaders is None:
loaders = []
for loader_name in settings.TEMPLATE_LOADERS:
loader = find_template_loader(loader_name)
if loader is not None:
loaders.append(loader)
template_source_loaders = tuple(loaders)
for loader in template_source_loaders:
try:
source, display_name = loader.load_template_source(name,
dirs)
return (source, make_origin(display_name, loader, name,
dirs))
except TemplateDoesNotExist:
pass
except NotImplementedError:
pass
raise TemplateDoesNotExist(name)


If you want to use the cache loader too, you'd have to subclass it and
define your own load_template_source() implementation.  I hope this
functionality gets added back to the core.  There isn't any reason not
to that I can see.

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

find_template Django 1.3

[demalexx]

Hello,

In Django 1.3 templates work a little different, in particular,
`find_template` returns compiled Template object, not template source.
There is a ticket here https://code.djangoproject.com/ticket/15102 but
last entry is 4 months old and I can't tell from discussion whether in
future Django will allow to get template source, or not.

So, can I somehow get template source with 1.3, and will Django allow
me get template source in the future?

Why I need it, my use case. I used it to send emails:

1. Get template source;
2. Prepend source by some additional template tags/filter, like "{%
load my_template_utils %}", so these tags/filters could be used
without explicitly adding them into each template;
3. Append footer, the same for all emails;
4. Render composed template and send email.

I know, this could be rewritten without getting template source, but I
think it will be less convenient for template authors.

Thank you.

-- 
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: chrome v13 + double-running middleware (django 1.3)

[Yeled Nova]

Instead of printing out Watchdog, you can "print request.path" to see
which two requests are triggering the middleware.

When you know which additional request is causing the problem, you can
use a decorator to filter it. Here is what I do:

---
In middleware.py:

Class MyMiddleWare:
@forNonStaticRequest
def process_request(self, request):
 # Your code goes here
 pass
---


And, somewhere else in your project:
===
from functools import wraps
from YOURPROJECTNAME.settings import DEBUG

def __forNonStaticRequest(func):
@wraps(func)
def wrapper(SELF, request):
prefix = ('/js/', '/images/', '/upload/', '/style/', '/
__debug__/')
if request.path.startswith(prefix):
return None
return func(SELF, request)
return wrapper

forNonStaticRequest = __forNonStaticRequest if DEBUG else (lambda u:
u)
===

What these codes do is to prevent static files request from triggering
the middleware *only* when you're running development server.
You need to properly handle static files when you actually deploy them
in production environment.

I think this will help you.


On Aug 23, 1:17 am, mcrk  wrote:
> Hi everyone!
>
> I've created a simple middleware for mobile detection and when testing
> values in dev console I came up with some pretty strange behavior.
> Let's say, I have this simple middleware class:
>
> class MobileRedirect(object):
>     def process_request(self, request):
>         print "watchdog"
>         return None
>
> and of course it's loaded in my settings:
>
> 'django.contrib.messages.middleware.MessageMiddleware',
> 'middleware.mobile_redirect.MobileRedirect',
>
> and when I go into my login page, this is the results I get in
> Firefox:
>
> watchdog
> [22/Aug/2011 19:08:02] "GET /login/ HTTP/1.1" 200 742
> [22/Aug/2011 19:08:02] "GET /static/css/base.css HTTP/1.1"
> [22/Aug/2011 19:08:02] "GET /static/css/fonts/OpenSans/Ope
> /1.1" 304 0
>
> and this is using Chrome v13:
>
> watchdog
> [22/Aug/2011 19:09:41] "GET /login/ HTTP/1.1" 200 742
> [22/Aug/2011 19:09:41] "GET /static/css/base.css HTTP/1.1" 2
> [22/Aug/2011 19:09:41] "GET /static/css/fonts/OpenSans/OpenS
> /1.1" 304 0
> watchdog
>
> "watchdog" is printed out twice, when using chrome!! Using IE gives
> the same result as FF.. so how on earth is chrome running the
> middleware twice??
>
> Can anyone please make a similar test and let me know, if You get the
> same problem.. or just tell me, if I'm doing smth wrong here. I'm new
> to django..
>
> Thanks in advance

-- 
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: Django 1.3 logging not working as I'd expect

[Gelonida N]

On 08/20/2011 06:51 AM, Scott Danzig wrote:
> I have Django 1.3 working with Python 2.7 and MySQL 5.5 on Mac OSX Lion...
> 
> I'm betting I'm missing something straight forward, but:
> 
> I have a simple Django app in development that uses a dictConfig setting
> simpler than the default in settings.py:
> 
> LOGGING = {
> 'version': 1,
> 'disable_existing_loggers': False,
> 'formatters': {
> 'verbose': {
> 'format': '%(levelname)s %(asctime)s %(module)s %(process)d
> %(thread)d %(message)s'
> },
> },
> 'handlers': {
> 'console':{
> 'level':'DEBUG',
> 'class':'logging.StreamHandler',
> 'formatter': 'verbose'
> },
> 'file':{
> 'level':'DEBUG',
> 'class':'logging.FileHandler',
> 'formatter': 'verbose',
> 'filename': 'testdjango.log',
> },
> },
> 'loggers': {
> 'testlogger': {
> 'handlers': ['console','file'],
> 'level': 'DEBUG',
> 'propagate': True,
>},
> },
> }
> 
> 
> Then later in code that I know is run... (I tried in my app's views.py
> and also the backend).. I put something like this:
> 
> import logging
> logger = logging.getLogger('testlogger')
> logger.warn('hello')
> logger.info('please appear')
> 
> 
> And I just don't see it, neither in the console, nor the file.
> 
> I have also tried something like this:
> import logging
> logger = logging.getLogger('otherlogger')
> hdlr = logging.FileHandler('newlogger.log')
> formatter = logging.Formatter('%(asctime)s %(levelname)s %(message)s')
> hdlr.setFormatter(formatter)
> logger.addHandler(hdlr) 
> logger.setLevel(logging.DEBUG)
> logger.warn('In settings.py!')
> 
You  have to be sure, that logging is configured before actually logging
anything.

So before your three lines:
> import logging
> logger = logging.getLogger('otherlogger')
> logger.warn('hello')
you had to be sure, that the django settings and thus the logging
configuration has really been completed.


You could for example add following two lines before:
> from django.conf import settings
> LOGGING = settings.LOGGING # force import

The second line is needed, as the first line is a 'lazy import' and will
only read the settings and configure logging  when you access the first
time a element of settings.
I just used settings.LOGGING, as it should always exist, when you try to
log.


I am not sure whether there is a more elegant solution.
When I asked this question recently on this list, I didn't receive any
other suggestions.




> And that doesn't work either, unless I put it right in settings.py.. in
> which case it appears 4 times, because, from what I understand,
> settings.py gets loaded that many times.  But then this doesn't work in
> the views.py/backend .. perhaps because the dictConfig gets loaded after
> settings.py is run?  I don't know.
> 
> I'm hoping for someone to give me a heads up about what I'm missing
> here.  Django's been pretty easy to deal with until I started to look
> into logging.
> 
> Thanks.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/JvmqgFNPMu4J.
> 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.


-- 
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: chrome v13 + double-running middleware (django 1.3)

[Daniel Roseman]

On Monday, 22 August 2011 18:17:09 UTC+1, mcrk wrote:
>
> Hi everyone! 
>
> I've created a simple middleware for mobile detection and when testing 
> values in dev console I came up with some pretty strange behavior. 
> Let's say, I have this simple middleware class: 
>
> class MobileRedirect(object): 
> def process_request(self, request): 
> print "watchdog" 
> return None 
>
> and of course it's loaded in my settings: 
>
> 'django.contrib.messages.middleware.MessageMiddleware', 
> 'middleware.mobile_redirect.MobileRedirect', 
>
> and when I go into my login page, this is the results I get in 
> Firefox: 
>
> watchdog 
> [22/Aug/2011 19:08:02] "GET /login/ HTTP/1.1" 200 742 
> [22/Aug/2011 19:08:02] "GET /static/css/base.css HTTP/1.1" 
> [22/Aug/2011 19:08:02] "GET /static/css/fonts/OpenSans/Ope 
> /1.1" 304 0 
>
> and this is using Chrome v13: 
>
> watchdog 
> [22/Aug/2011 19:09:41] "GET /login/ HTTP/1.1" 200 742 
> [22/Aug/2011 19:09:41] "GET /static/css/base.css HTTP/1.1" 2 
> [22/Aug/2011 19:09:41] "GET /static/css/fonts/OpenSans/OpenS 
> /1.1" 304 0 
> watchdog 
>
> "watchdog" is printed out twice, when using chrome!! Using IE gives 
> the same result as FF.. so how on earth is chrome running the 
> middleware twice?? 
>
> Can anyone please make a similar test and let me know, if You get the 
> same problem.. or just tell me, if I'm doing smth wrong here. I'm new 
> to django.. 
>
> Thanks in advance


Chrome is probably making a request for /favicon.ico, which is being routed 
through your middleware.
--
DR. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/dMzQekzzDBsJ.
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.

chrome v13 + double-running middleware (django 1.3)

[mcrk]

Hi everyone!

I've created a simple middleware for mobile detection and when testing
values in dev console I came up with some pretty strange behavior.
Let's say, I have this simple middleware class:

class MobileRedirect(object):
def process_request(self, request):
print "watchdog"
return None

and of course it's loaded in my settings:

'django.contrib.messages.middleware.MessageMiddleware',
'middleware.mobile_redirect.MobileRedirect',

and when I go into my login page, this is the results I get in
Firefox:

watchdog
[22/Aug/2011 19:08:02] "GET /login/ HTTP/1.1" 200 742
[22/Aug/2011 19:08:02] "GET /static/css/base.css HTTP/1.1"
[22/Aug/2011 19:08:02] "GET /static/css/fonts/OpenSans/Ope
/1.1" 304 0

and this is using Chrome v13:

watchdog
[22/Aug/2011 19:09:41] "GET /login/ HTTP/1.1" 200 742
[22/Aug/2011 19:09:41] "GET /static/css/base.css HTTP/1.1" 2
[22/Aug/2011 19:09:41] "GET /static/css/fonts/OpenSans/OpenS
/1.1" 304 0
watchdog

"watchdog" is printed out twice, when using chrome!! Using IE gives
the same result as FF.. so how on earth is chrome running the
middleware twice??

Can anyone please make a similar test and let me know, if You get the
same problem.. or just tell me, if I'm doing smth wrong here. I'm new
to django..

Thanks in advance

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