Django talk

Wednesday, March 30, 2016

Re: Migrating older 1.4 project to 1.9

I have also upgraded a few apps this way, from 1.5 to 1.9. Keep your eyes on the release notes for each version for big changes. It also helps to have good test cases written so that you can run them upon each upgrade.

From: "Gergely Polonkai" <gergely@polonkai.eu>
To: "Django users" <django-users@googlegroups.com>
Sent: Wednesday, March 30, 2016 1:06:45 PM
Subject: Re: Migrating older 1.4 project to 1.9

I have already suggested this approach to someone with a similar problem: upgrade one version at a time. I'm sure it is possible to find older versions; 1. upgrade to the next minor release (1.4 => 1.5, etc), 2. do the necessary adjustments, 3. goto 1.

It may be a lot of work, but at the end of the day you will have a perfectly upgraded application. I have successfully upgraded 3 apps this way, one of them being really big (tens of thousands of code lines).

Roger,

Yeah, I too have a large project that I'll hopefully be migrating
from 1.4 to 1.9 soon.

It's about 3.5 years worth of work, over 200,000 lines of code
in about 1000 Python source file and Django template files.

So any tips you come up with will be invaluable. Please post
anything you learn to this thread.

Thanks!

--Fred

Fred Stluka -- mailto:fred@bristle.com -- http://bristle.com/~fred/
Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
Open Source: Without walls and fences, we need no Windows or Gates.

On 3/30/16 9:23 AM, bobhaugen wrote:

We feel your pain. If you do it, and write down how it goes, we would be grateful.
https://github.com/valnet/valuenetwork

On Tuesday, March 29, 2016 at 4:19:59 PM UTC-5, Roger Dunn wrote:

I've inherited a moderately large project written 2 years ago using Django 1.4, and wondering if it is worth creating a fresh 1.9 project and porting in the old code, or doing an in-place upgrade to 1.9?

I have it running on 1.4 'as is' but if I run python manage.py migrate it comes unglued as a lot of stuff has changed since 1.4.

--
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+unsubscribe@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/2a3de1fc-5032-4807-b008-66f2e381ac7f%40googlegroups.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+unsubscribe@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/56FBDDBE.9020409%40bristle.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+unsubscribe@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/CACczBU%2BhDnDtD4WwkAPGWc4W0Zq9wz-iK%3DdmcNn0ONAijG8feQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: POSSIBLE BUG: using Coalesce() with __in=[]

Thank you Simon!

I'll file a bug and include a link here, including your points. Your source documentation was incredibly helpful.

On Wednesday, March 30, 2016 at 12:03:10 PM UTC-5, Simon Charette wrote:

Hi Ryan,

I think this should be considered a bug.

From what I understand the ORM simply doesn't perform any query in this case
as the `pk__in` lookup cannot match any `OrderItem` and result in an
`EmptyResultSet` exception[1].

This exception is caught in the `Query.get_aggregation()` method where all
aggregates are converted to `None`[2].

I suppose we should alter the `except EmptyResultSet` clause to account for
`outer_query.annotation_select` items that are `Coalesce()` instances used with
`Value()` but I'm unsure about how it should be done.

I think this will be hard to fix correctly as `Coalesce` can be nested.

e.g.

# This should return `0`
Coalesce(Coalesce(Sum('quantity'), Value(0)), F('other_field'))

Cheers,
Simon

[1] https://github.com/django/django/blob/2e0cd26ffb29189add1e0435913fd1490f52b20d/django/db/models/lookups.py#L221-L223
[2] https://github.com/django/django/blob/2e0cd26ffb29189add1e0435913fd1490f52b20d/django/db/models/sql/query.py#L439-L445

Le mercredi 30 mars 2016 12:27:49 UTC-4, Ryan Prater a écrit :
It seems that using an empty list when using the `__in=` filter prevents an Aggregate Coalesce from working properly. See below:

# Test with matched Queryset. Sum will return 50
OrderItem.objects.filter(pk__in=[1]).aggregate(test=Coalesce(Sum('quantity'), Value(0)))
>>> {'test': 50}

# Test with unmatched Queryset. Sum will return 0
OrderItem.objects.filter(pk__in=[-1]).aggregate(test=Coalesce(Sum('quantity'), Value(0)))
>>> {'test':0}

# Test with unmatched Queryset (using empty list). Sum will return NONE
OrderItem.objects.filter(pk__in=[]).aggregate(test=Coalesce(Sum('quantity'), Value(0)))
>>> {'test': None}

Can someone confirm? I will post as a bug if so.

--
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+unsubscribe@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/bc6081b8-71b1-4643-98da-9abb10b51d82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Why doesn't {{ form.field.value }} return cleaned data?

Say I have a TypedMultipleChoiceField and I'm building a custom select multiple widget in my template.

If I want to check a box based on an initial value (ie. default checked options), OR check a box based on form data that has been returned (ie. error state), I would do this:

HOWEVER, {{form.field.value}} source documentation (boundfield.py) states: "Returns the value for this BoundField, using the initial value if the form is not bound or the data otherwise."

So basically the equivalent of:

return (form.field.data or form.field.initial)

Wouldn't it be more appropriate and useful for boundfield.value to return CLEANED data that has gone through to_python()? As in:

return (form.field.cleaned_data or form.field.initial)

--
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+unsubscribe@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/62a1b22e-3d8b-4241-bbf7-20145686ab33%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Model share question

I'm new to django and have a question regarding model design.

For practice, I'm working on a web app - a simplified version of imdb that handles movie and music.

I've created 2 apps; Movies and Music. With main models in both having the usual fields (title, release date, rating, artist/actor).

My problem is, I don't know where to put the Person model. I want it to be shared by both apps.

Should there be an app for Person and put the model in there?

Thanks.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@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/d28d97f6-37c6-4ef5-89d3-96d538e86b2c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Generate different querysets depending of the website language

Hello.

I have been doing some tests, here are my results :

The Django default language (fallback) is in Spanish in all case

No IgnoreHTTPLanguageMiddleware

Browser having English has priority

URL specified language in Spanish /es/

-> Translated blocks in Spanish

-> Language related DB queries in English

URL specified language in English /en/

-> Translated blocks in English

-> Language related DB queries in English

No IgnoreHTTPLanguageMiddleware

Browser having Spanish has priority

URL specified language in Spanish /es/

-> Translated blocks in Spanish