Re: Issue 14878 And Changeset 15133

[Gert Van Gool]

Not really related to #5373, since it's related to the new generic views code.

-- Gert

Mobile: +32 498725202
Twitter: @gvangool
Web: http://gert.selentic.net


On Fri, Jan 7, 2011 at 00:26, Lachlan Musicman  wrote:
>
> 2011/1/7 Diego Andrés Sanabria Martín :
> > A few weeks ago i report this issue, 14878[1], and Rusell fix it, but
> > i think still there is a possible bug, if the verbose name of a model
> > includes a translation string.
>
> Is this related to http://code.djangoproject.com/ticket/5373 ?
>
> cheers
> L.
>
>
> --
> "... imagine a puddle waking up one morning and thinking, 'This is an
> interesting world I find myself in - an interesting hole I find myself
> in - fits me rather neatly, doesn't it? In fact it fits me
> staggeringly well, must have been made to have me in it!' This is such
> a powerful idea that as the sun rises in the sky and the air heats up
> and as, gradually, the puddle gets smaller and smaller, it's still
> frantically hanging on to the notion that everything's going to be
> alright, because this world was meant to have him in it, was built to
> have him in it; so the moment he disappears catches him rather by
> surprise."
> Douglas Adams
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>

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

User model being included by default

[Antony Vennard]

Hello all,

For various reasons a client of mine requested that, other than using a
framework of their choice, I implement an authentication system
following their spec. I used Django and implemented my own app which
contains the usual models.py which implements a user object and so on.

Django has been updated via my package manager several times since I
last tested my code. I've now come back to that and what was previously
working is breaking like so:

DatabaseError at /
column auth_user.first_name does not exist
LINE 1: SELECT "auth_user"."id", "auth_user"."username", "auth_user"...

This happens when I import my own models.py and try to
User.objects.anymethod()

Now, my model "User" doesn't contain the same fields as Django's
obviously, so the conclusion is that Django's User model is being
included when I've not asked it to be.

Relevant parts from Settings.py:

TEMPLATE_LOADERS = (
'django.template.loaders.filesystem.Loader',
'django.template.loaders.app_directories.Loader',
'django.template.loaders.eggs.Loader',
)

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

ROOT_URLCONF = 'Testbed.urls'

TEMPLATE_DIRS = (
"/var/www/Django/Testbed/testapp/templates",
"/var/www/Django/Testbed/authadmin/templates",
)

AUTHENTICATION_BACKENDS = ('')

TEMPLATE_CONTEXT_PROCESSORS = (
"vxd.auth.contexts.Authentication",
)

INSTALLED_APPS = (
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'reversetag',
'markitup',
'vxd.auth',
'Testbed.authadmin',
'Testbed.testapp',
)

Can anyone please explain what's changed?

Likewise, I get various strange errors on a similar project using my
system when I try to access the request.session["username"] key.

An alternative is a project-wide rename; still, this isn't ideal.

Thanks,

A

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

Re: SQL join promotion as a result of querying for a NULL value

[Byron Ruth]

> Just to be clear: The assumption is that if:
>         1) the user filtered on a related model's field
>         2) with is_null=True, and
>         3) there is a nullable FK in the chain leading to the filtered field
>            (this is checked by promote_alias_chain),
> then:
> use a left outer join.

Indeed.

> Not at all (given the full set of assumptions as I've described). How else
> would you express your will to have a left join?

I have used Django for quite a while now and clearly I have never run
into this before, so I agree that it isn't a _bad_ default, but rather
it somewhat surprised me when I found out the behavior. I also am not
arguing that the assumptions are wrong, but rather there are
implications that are not obvious (until you run into it).

> Really, it's mostly a case where the Django ORM query language is not as
> expressive as SQL; I think the choice made by Django here is for the more
> common case.

Absolutely.

> You can limit the rows to "real" rows by adding a condition such as
> related__pk__isnull=False. With current code, as far as I understand it, this
> will still do a left join, but pick from it only "real" rows; the question
> then becomes one of performance, not correctness.
> This also validates the decision to do a left join when in doubt: From there,
> you can restore inner-join semantics. You can't go the other way around.

Yep, that is the solution I have fallen back to in the meantime.

> I think a better, more general approach would be to allow explicit setting of
> join methods:
>
> qs.join_methods(rel1=Inner, rel2__rel2A=Left)

I honestly wouldn't mind if it wasn't even public API (as with the
QuerySet), my use case is non-traditional and in many cases I am using
the internal queryset.query API for some of my joins. It currently is
more of issue that the logic is deep and non-configurable. Possibly a
flag that gets propagated down to query.add_filter() to prevent
promotion to LOJ.

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

Re: Regressions in 1.2.4

[Luke Plant]

FWIW, I'm inclined to agree with James and Gabriel that having security
only releases on the bugfix branch will increase confusion, and will
increase the likelihood that human error with regards to packages (both
by the Django team and by Django users) is the cause of both more
security problems and more regressions.

Gabriel wrote:

> 1) Even security patches can introduce regressions, so creating a
> security-fix only branch doesn't inherently provide a regression-free
> branch; it only make it less likely by decreasing the number of
> changes which could potentially contain a bug.

A case in point being the admin lookup security fix in 1.2.4.

Luke

-- 
"Underachievement: The tallest blade of grass is the first to be 
cut by the lawnmower." (despair.com)

Luke Plant || http://lukeplant.me.uk/

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

Re: SQL join promotion as a result of querying for a NULL value

[Shai Berger]

On Thursday 06 January 2011, Byron Ruth wrote:
> I am speaking of this particular if statement:
> http://code.djangoproject.com/browser/django/tags/releases/1.2.4/django/db/
> models/sql/query.py#L1051
> 
> There are a few implications of this assumption.

Just to be clear: The assumption is that if:
1) the user filtered on a related model's field 
2) with is_null=True, and 
3) there is a nullable FK in the chain leading to the filtered field
   (this is checked by promote_alias_chain), 
then:
use a left outer join. 

> One being, that if
> the user is actually trying to get the "real" rows that exist with a
> column that has a NULL value, they will get those in addition to all
> the rows generated that are empty as a result of the LEFT OUTER JOIN.
> 
[...]
> 
> This seems like very strange behavior to have by default.

Not at all (given the full set of assumptions as I've described). How else 
would you express your will to have a left join?

Really, it's mostly a case where the Django ORM query language is not as 
expressive as SQL; I think the choice made by Django here is for the more 
common case.

> I suggest
> there be a way to prevent the joins from being promoted to LEFT OUTER
> JOIN when the specifying a QuerySet condition using NULL values.
> 

Besides the suggestion made by Philippe Raoult:
> use exclude(related__field__isnull = False) instead of
> filter(related__field__isnull = True) to avoid this issue.
You can limit the rows to "real" rows by adding a condition such as 
related__pk__isnull=False. With current code, as far as I understand it, this 
will still do a left join, but pick from it only "real" rows; the question 
then becomes one of performance, not correctness.
This also validates the decision to do a left join when in doubt: From there, 
you can restore inner-join semantics. You can't go the other way around.

> Obviously the fact that people have been relying on this behavior for
> 2+ years either proves to be the correct assumption or not many have
> come across these scenarios. I propose exposing a small API that
> allows for keeping INNER JOINs and not promoting simply because of a
> NULL value.
> 

I think a better, more general approach would be to allow explicit setting of 
join methods:

qs.join_methods(rel1=Inner, rel2__rel2A=Left)

My 2 cents,
Shai.

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

Re: Issue 14878 And Changeset 15133

[Lachlan Musicman]

2011/1/7 Diego Andrés Sanabria Martín :
> A few weeks ago i report this issue, 14878[1], and Rusell fix it, but
> i think still there is a possible bug, if the verbose name of a model
> includes a translation string.

Is this related to http://code.djangoproject.com/ticket/5373 ?

cheers
L.


-- 
"... imagine a puddle waking up one morning and thinking, 'This is an
interesting world I find myself in - an interesting hole I find myself
in - fits me rather neatly, doesn't it? In fact it fits me
staggeringly well, must have been made to have me in it!' This is such
a powerful idea that as the sun rises in the sky and the air heats up
and as, gradually, the puddle gets smaller and smaller, it's still
frantically hanging on to the notion that everything's going to be
alright, because this world was meant to have him in it, was built to
have him in it; so the moment he disappears catches him rather by
surprise."
Douglas Adams

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

Re: SQL join promotion as a result of querying for a NULL value

[Philippe Raoult]

I too was rather surprised by this behavior. I have since changed my
code to use exclude(related__field__isnull = False) instead of
filter(related__field__isnull = True) to avoid this issue.

I'm all for an API, but I'm not sure which would be best. Maybe
filter(related__field__isnull_nopromote = True) ? This isn't
particularly elegant though. I'd prefer filter(related__field__isnull
= True, no_promote = True) but that would forbid users from using
no_promote as a field name.

Another backward-compatible way would be to add a no_promote() method
to the queryset:
Model.objects.no_promote().filter(related__field__isnull = True)



On 6 January 2011 22:13, Byron Ruth  wrote:
> I am speaking of this particular if statement:
> http://code.djangoproject.com/browser/django/tags/releases/1.2.4/django/db/models/sql/query.py#L1051
>
> There are a few implications of this assumption. One being, that if
> the user is actually trying to get the "real" rows that exist with a
> column that has a NULL value, they will get those in addition to all
> the rows generated that are empty as a result of the LEFT OUTER JOIN.
>
> Given the example:
>
>    SELECT * FROM table1 INNER JOIN table2 ON (table2.table1_id =
> table1.id) WHERE table2.foo IS NULL
>
> With the INNER JOIN, if table2 is empty, no rows will return. Any
> table2 rows that match 'foo IS NULL' will return if and only if it
> references a row in table1 (obviously if table1_id is not nullable,
> this will always be true).
>
>    SELECT * FROM table1 LEFT OUTER JOIN table2 ON (table2.table1_id =
> table1.id) WHERE table2.foo IS NULL
>
> With the LEFT OUTER JOIN, if table2 is empty, all of the rows from
> table1 will return! In addition, any rows in table2 that match 'foo IS
> NULL' will return as well as the ones that don't have rows that exist
> in the table!
>
> This seems like very strange behavior to have by default. I suggest
> there be a way to prevent the joins from being promoted to LEFT OUTER
> JOIN when the specifying a QuerySet condition using NULL values.
>
> Obviously the fact that people have been relying on this behavior for
> 2+ years either proves to be the correct assumption or not many have
> come across these scenarios. I propose exposing a small API that
> allows for keeping INNER JOINs and not promoting simply because of a
> NULL value.
>
> Any thoughts or feedback on this argument?
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

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

Re: contrib 's FormWizard needs a lot of work

[David Durham]

On Thu, Jan 6, 2011 at 4:22 PM, Stephan Jäkel  wrote:
> Hi David,
>
> you should take a look at the NamedUrlFormWizard. In this second approach,
> after successful posting a form, a redirect is done to get the user to the
> next step. Is this the point you meant?
>
> Using the NamedUrlFormWizard, it's also possible to display links to
> different steps.


Ah, yes.  I see it right there in NamedUrlFormWizard.render_next_step.
 I approve.  Good work.

-Dave

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

Re: contrib 's FormWizard needs a lot of work

[Stephan Jäkel]

Hi David,

you should take a look at the NamedUrlFormWizard. In this second approach, 
after successful posting a form, a redirect is done to get the user to the 
next step. Is this the point you meant?


Using the NamedUrlFormWizard, it's also possible to display links to 
different steps.


Cheers,

Stephan

David Durham wrote:

If I'm reading this code correctly:

   
https://github.com/stephrdev/django-formwizard/blob/master/formwizard/forms.py

I think this implementation misses the core point I was trying to
address with #9200, that you should not have to POST in order to
navigate to a step/form in the wizard.  My implementation of course
was not as robust as the current one, but I think the point about
successful POST of a step/form should redirect to GET the next step is
valid.  This is I think what leads to correct back/forward browser
navigation, and it also enables you to easily display links to
different steps in the wizard.

Please correct (or ignore) me, if I am mistaken.

Thanks,
Dave


On Sun, Jan 2, 2011 at 11:51 AM, Miguel Araujo
  wrote:

Hi Stephan,
Sorry If I didn't answer before, I have been on vacations.
I have given you some feedback in my pull
request: https://github.com/stephrdev/django-formwizard/pull/5
I will start soon writing a draft and trying to help you make
django-formwizard the official replacement.
Cheers,

Miguel Araujo
@maraujop
2010/12/31 Stephan Jäkel

Hi,

I just updated the cbv_refactor branch to use the generic class based
views from Django trunk. I hope everything works as supposed.

I would appreciate any help on writing documentation - even if its just a
draft but its a beginning ;-)

Looking forward to feedback!

Cheers,

steph

Miguel Araujo wrote:

Hi Stephan,

I'm sorry but I didn't get any answer on Github :)

In that case, if you already discussed it with Jannie Leidel and Russell
Keith-Magee, then I guess they liked the idea of replacing it with you
app
when it has some more work done. In that case if you are planning on
working
on it, I can offer you my humble help with anything you need. I can do my
best documenting it in English, though I make mistakes often. I read the
code thoroughly and all I did to it is in my fork. Hopefully the back
browser's button will be fixed with class based views.

If you want me I can work on a how-to draft with some basics on how to
setup
your app and get some basic wizards running.

Only thing that disturbs my sleeping is the singleton issue. I would like
someone can clarify why the singleton has a per interpreter scope instead
of
request scope.

Kind regards,


Miguel Araujo
@maraujop



2010/12/26 Stephan Jäkelmailto:m...@sjaekel.com>>

Hi Miguel,

I saw your message on GitHub and I thought I had answered that I'll
work
on the formwizard within the next weeks. But maybe I missed to press
the
"send" button :-)

Regarding your points, I had the same thoughts in 02/2010 and started
to
write django-formwizard. There were also some discussions with Jannis
Leidel and Russell Keith-Magee about replacing the current formwizard
with django-formwizard.

Currently, the first changes in Django, which are needed for the
upload
stuff, were done and my next plan is to update the cbv refactor branch
to use the class based views coming with Django 1.3. The next big
thing
will be extending the docs.

After moving to class based views, your points should be solved, I
think.

Within the next days the 27c3
(http://events.ccc.de/congress/2010/wiki/Main_Page) occurs in Berlin.
I
will be there and will work on django-formwizard and I hope to come
back
with some news.

Cheers,

steph


Miguel Araujo wrote:

Hi everyone,

I think FormWizard solves a common problem when you need forms to
be
split
into steps, many frameworks have solutions to this pattern. I
started using
it and soon realized there is much left to be done and it looks
like
it's
been postponed too long.

In brief it's missing support for:
- Formsets http://code.djangoproject.com/ticket/2
- Session backend http://code.djangoproject.com/ticket/9200
- Multipart forms http://code.djangoproject.com/ticket/7439
- Others

One that I actually think needs to be discussed is ticket
http://code.djangoproject.com/ticket/8808 Problem is that it looks
like
FormWizard is treated as a singleton and it also appears to me
that
Singleton objetcs within Django have per interpreter process
instance scope,
which I would have supposed to be per request scope. So setting
variables
using self is a time bomb. Sure you can use request.session to
pass
variables within methods, but no where in the docs this is stated.
So many
people end up using it and having obscure bugs they don't
understand.

I first thought about imp

SQL join promotion as a result of querying for a NULL value

[Byron Ruth]

I am speaking of this particular if statement:
http://code.djangoproject.com/browser/django/tags/releases/1.2.4/django/db/models/sql/query.py#L1051

There are a few implications of this assumption. One being, that if
the user is actually trying to get the "real" rows that exist with a
column that has a NULL value, they will get those in addition to all
the rows generated that are empty as a result of the LEFT OUTER JOIN.

Given the example:

SELECT * FROM table1 INNER JOIN table2 ON (table2.table1_id =
table1.id) WHERE table2.foo IS NULL

With the INNER JOIN, if table2 is empty, no rows will return. Any
table2 rows that match 'foo IS NULL' will return if and only if it
references a row in table1 (obviously if table1_id is not nullable,
this will always be true).

SELECT * FROM table1 LEFT OUTER JOIN table2 ON (table2.table1_id =
table1.id) WHERE table2.foo IS NULL

With the LEFT OUTER JOIN, if table2 is empty, all of the rows from
table1 will return! In addition, any rows in table2 that match 'foo IS
NULL' will return as well as the ones that don't have rows that exist
in the table!

This seems like very strange behavior to have by default. I suggest
there be a way to prevent the joins from being promoted to LEFT OUTER
JOIN when the specifying a QuerySet condition using NULL values.

Obviously the fact that people have been relying on this behavior for
2+ years either proves to be the correct assumption or not many have
come across these scenarios. I propose exposing a small API that
allows for keeping INNER JOINs and not promoting simply because of a
NULL value.

Any thoughts or feedback on this argument?

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

Re: Regressions in 1.2.4

[Gabriel Hurley]

On Thursday, January 6, 2011 6:29:32 AM UTC-8, James Bennett wrote:
>
> It'd also be a major
> maintenance/bookkeeping headache and, I think, *more* likely to result
> in us accidentally crossing the streams while trying to keep track of
> what goes on in which branch.
>
I have the same concern here. With an A.B.C.D system my concern is that a 
lot of people would simply be confused. It'd be confusing enough for the 
core team to manage, let alone trying to explain it to users.

> Personally, I'd be in favor of keeping the overall release process
> as-is -- one release branch, which gets all bugfixes while applicable,
> plus highlighting the individual security patches as released -- and
> providing better documentation of what the release branch really is
> (i.e., not a security-only branch) and how to pull just a security
> update if that's what you want.
>
 +1 on that. As long as it's easy for people who *only* want the security 
patches to get them without any other updates I think that's fine.

>From a slightly more philosophical point of view, I'll add two other points 
of consideration:

1) Even security patches can introduce regressions, so creating a 
security-fix only branch doesn't inherently provide a regression-free 
branch; it only make it less likely by decreasing the number of changes 
which could potentially contain a bug.

2) Any bug is a potential liability for a user. While the bugs that are 
serious enough to trigger security releases are more urgent, there is a 
statistical net gain to having all the fixes included in the branch. While 
it's psychologically frustrating to a user to upgrade and be faced with a 
new regression that was previously unknown, from a purely mathematical 
standpoint you're actually better off in the aggregate.

All that is to say that a 1.2.5 release is completely appropriate and I'm +1 
for it, and I think it's better to continue as we have and be as responsive 
and responsible as possible when new regressions are found.

That's my two cents,

- Gabriel

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

Re: contrib 's FormWizard needs a lot of work

[David Durham]

If I'm reading this code correctly:

  https://github.com/stephrdev/django-formwizard/blob/master/formwizard/forms.py

I think this implementation misses the core point I was trying to
address with #9200, that you should not have to POST in order to
navigate to a step/form in the wizard.  My implementation of course
was not as robust as the current one, but I think the point about
successful POST of a step/form should redirect to GET the next step is
valid.  This is I think what leads to correct back/forward browser
navigation, and it also enables you to easily display links to
different steps in the wizard.

Please correct (or ignore) me, if I am mistaken.

Thanks,
Dave


On Sun, Jan 2, 2011 at 11:51 AM, Miguel Araujo
 wrote:
> Hi Stephan,
> Sorry If I didn't answer before, I have been on vacations.
> I have given you some feedback in my pull
> request: https://github.com/stephrdev/django-formwizard/pull/5
> I will start soon writing a draft and trying to help you make
> django-formwizard the official replacement.
> Cheers,
> 
> Miguel Araujo
> @maraujop
> 2010/12/31 Stephan Jäkel 
>>
>> Hi,
>>
>> I just updated the cbv_refactor branch to use the generic class based
>> views from Django trunk. I hope everything works as supposed.
>>
>> I would appreciate any help on writing documentation - even if its just a
>> draft but its a beginning ;-)
>>
>> Looking forward to feedback!
>>
>> Cheers,
>>
>> steph
>>
>> Miguel Araujo wrote:
>>>
>>> Hi Stephan,
>>>
>>> I'm sorry but I didn't get any answer on Github :)
>>>
>>> In that case, if you already discussed it with Jannie Leidel and Russell
>>> Keith-Magee, then I guess they liked the idea of replacing it with you
>>> app
>>> when it has some more work done. In that case if you are planning on
>>> working
>>> on it, I can offer you my humble help with anything you need. I can do my
>>> best documenting it in English, though I make mistakes often. I read the
>>> code thoroughly and all I did to it is in my fork. Hopefully the back
>>> browser's button will be fixed with class based views.
>>>
>>> If you want me I can work on a how-to draft with some basics on how to
>>> setup
>>> your app and get some basic wizards running.
>>>
>>> Only thing that disturbs my sleeping is the singleton issue. I would like
>>> someone can clarify why the singleton has a per interpreter scope instead
>>> of
>>> request scope.
>>>
>>> Kind regards,
>>>
>>> 
>>> Miguel Araujo
>>> @maraujop
>>>
>>>
>>>
>>> 2010/12/26 Stephan Jäkel mailto:m...@sjaekel.com>>
>>>
>>>    Hi Miguel,
>>>
>>>    I saw your message on GitHub and I thought I had answered that I'll
>>> work
>>>    on the formwizard within the next weeks. But maybe I missed to press
>>> the
>>>    "send" button :-)
>>>
>>>    Regarding your points, I had the same thoughts in 02/2010 and started
>>> to
>>>    write django-formwizard. There were also some discussions with Jannis
>>>    Leidel and Russell Keith-Magee about replacing the current formwizard
>>>    with django-formwizard.
>>>
>>>    Currently, the first changes in Django, which are needed for the
>>> upload
>>>    stuff, were done and my next plan is to update the cbv refactor branch
>>>    to use the class based views coming with Django 1.3. The next big
>>> thing
>>>    will be extending the docs.
>>>
>>>    After moving to class based views, your points should be solved, I
>>> think.
>>>
>>>    Within the next days the 27c3
>>>    (http://events.ccc.de/congress/2010/wiki/Main_Page) occurs in Berlin.
>>> I
>>>    will be there and will work on django-formwizard and I hope to come
>>> back
>>>    with some news.
>>>
>>>    Cheers,
>>>
>>>    steph
>>>
>>>
>>>    Miguel Araujo wrote:
>>>
>>>        Hi everyone,
>>>
>>>        I think FormWizard solves a common problem when you need forms to
>>> be
>>>        split
>>>        into steps, many frameworks have solutions to this pattern. I
>>>        started using
>>>        it and soon realized there is much left to be done and it looks
>>> like
>>>        it's
>>>        been postponed too long.
>>>
>>>        In brief it's missing support for:
>>>        - Formsets http://code.djangoproject.com/ticket/2
>>>        - Session backend http://code.djangoproject.com/ticket/9200
>>>        - Multipart forms http://code.djangoproject.com/ticket/7439
>>>        - Others
>>>
>>>        One that I actually think needs to be discussed is ticket
>>>        http://code.djangoproject.com/ticket/8808 Problem is that it looks
>>> like
>>>        FormWizard is treated as a singleton and it also appears to me
>>> that
>>>        Singleton objetcs within Django have per interpreter process
>>>        instance scope,
>>>        which I would have supposed to be per request scope. So setting
>>>        variables
>>>        using self is a time bomb. Sure you can use request.session to
>>> pass
>>>        variables within methods, but no where in the docs this is stated.
>>>        So many
>>>        people end up using it and ha

Re: app loading

[Alex Kamedov]

Hello Arthur, thanks for good work on this branch.

I've knew about APP_CLASSES on starting the topic, but I not understood why
it was not merged with INSTALLED_APPS.
Thank you for explanation. Now I see.

I found some problems with contrib applications and managment commands and
can produce patch to fix it.


Cheers!

On Wed, Jan 5, 2011 at 6:29 PM, Arthur Koziel wrote:

> Hey Alex,
>
> thanks for taking the time to review the code. However, we've agreed not to
> construct the app instances in the settings.py file as it would require
> imports to be used, and stick to the convention of dotted paths. You might
> want to read this thread [0], but especially this [1] reply from Jannis
> Leidel.
>
> We also discussed this whole thing at the DjangoCon sprints, which led us
> to the current implementation. There are now 2 settings with which apps can
> be installed:
>
> - APP_CLASSES: which is a list of dotted paths pointing to App classes
> - INSTALLED_APPS: stays the same, dotted paths to python modules
>
> Arthur
>
> [0]:
> http://groups.google.com/group/django-developers/browse_thread/thread/4cca2086dd485879/
> [1]: http://groups.google.com/group/django-developers/msg/fd2e3bc0593f4158
>
> On Sun, Jan 2, 2011 at 12:17 PM, Alex Kamedov  wrote:
>
>> Hi all! Happy new year!
>> Sorry for my bad english.
>>
>> On this weekend I reviewed app-loading branch[1] and want to propose some
>> improvements.
>>
>> Now app-loading branch resolve how to load application, store its meta
>> data and load its models.
>> I plan to extend it to get simple way for replacing the same type
>> applications. This problem is
>> know as Lazy Foreign Key and now can be resolve through settings, but
>> django contrib modules
>> currently is not supported it. I propose more beautiful way to resolve
>> this problem.
>>
>> The main goal of my improvements is adding ability to simple replace one
>> application to another
>> with the same type but another functionality.  For example, if you need
>> replace `django.contrib.auth`
>> on your own application you must rewrite all used 3rd-party applications
>> linked with it now. I
>> propose way to resolve this problem and I think It is not hard to
>> implement with saving backward
>> compatibilities.
>>
>>
>> 1. Change INSTALLED_APPS form tuple to dictionary or may be it's better to
>> use something with
>> the same interface as tuple and dictionary
>>
>> INSTALLED_APPS = {
>> 'auth': 'django.contrib.auth',
>> 'comments': 'django.contrib.comments'.
>> ...
>> }
>>
>> For backward compatibility it checks on setting load stage and convert to
>> dictionary if it need.
>>
>> INSTALLED_APPS will be low level API to install applications. I propose
>> install application through
>> `install_applications` function like this:
>>
>> from django.core.apps import install_applications
>>
>> INSTALLED_APPS = install_applications(
>> 'django.contrib.contenttypes',
>> 'django.contrib.sessions',
>> ...
>> auth = 'django.contrib.auth',
>> comments = 'django.contrib.comments'
>> gallery = App(path='my_gallery', db_prefix='new_gallery',
>> verbose_name=u'My new gallery')
>> )
>>
>>  There are args and kwargs passed to `install_applications`. It can be
>> python module names of
>> django applications. Keys of kwargs are system names of the installed
>> applications. This names
>> will be used to get application instance in other applications (see next
>> for more details).
>> For applications passed through args keys will be auto generated.
>>
>> The main benefit is a manage installed applications in project settings
>> module without make
>> changes in this applications.
>>
>> Application loading process will be as listed below:
>>  * iterate over INSTALLED_APPS items
>>  * if item is string - try to load application definition
>> (`Application`class) from python package
>> defined in this string and create its instance. If application
>> definition is not provided, it will be
>> auto generated. `django.core.apps.App` class will be used for it.
>>  * if item is `App` instance, check existence of python package at `path`
>> attribute of `App` instance
>>and `ImproperlyConfigured` exception will be raised if this python
>> package is not installed.
>>
>> 2. Way to organize relations between models of different applications
>> (something like this it
>> already exist in app-loading branch and trunk. I show this only for
>> example and demonstrate
>> syntax)
>>
>> from django.core.apps import get_app, get_model
>>
>> auth = get_app('auth')
>>
>> class MyModel(models.Model):
>> user = models.ForeignKey(auth.models.User)
>>
>> or
>>
>> class MyModel(models.Model):
>> user = models.ForeignKey(get_model('auth.User'))
>>
>>
>> 3. Add new exceptions: `AppIsNotInstalled` (instead of
>> `ImproperlyConfigured`) will be raised if it is
>> try to load not installed applications through `get_ap

Issue 14878 And Changeset 15133

[Diego Andrés Sanabria Martín]

A few weeks ago i report this issue, 14878[1], and Rusell fix it, but
i think still there is a possible bug, if the verbose name of a model
includes a translation string.

[1] http://code.djangoproject.com/ticket/14878
[2] http://code.djangoproject.com/changeset/15133

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

Re: Regressions in 1.2.4

[James Bennett]

On Wed, Jan 5, 2011 at 10:05 AM, Russell Keith-Magee
 wrote:
> We will obviously to do a 1.2.5 release when we hit 1.3 final; but I'm
> not sure if we should push an 1.2.5 (and 1.1.4) ASAP addressing these
> regressions, and then do 1.2.6 when we cut 1.3 final.

I'm in favor of doing 1.2.5 as soon as we know we've fixed the regressions.

> This also points out that we should perhaps reconsider our release
> policy. Putting out security releases that include unrelated fixes is
> a bit of a risk. We've been bitten by this in the past, but never this
> bad. I would suggest that when security issues arises in 1.2.3, we
> should be releaseing 1.2.3.1 rather than 1.2.4. If a security release
> coincides with a point release -- as it did when we released 1.3beta1
> -- we should release 1.2.3.1 (to address the security issue) *and*
> 1.2.4 (to get the other bugfixes). This will ensure that it is
> possible to update production code and get just the security fix,
> without any risk of regressions.

So, there are two valid use cases here:

1. "I want to run Django X.Y, and periodically get bugfixes for things
that weren't caught before the final release".

2. "I want to run Django X.Y and only care about security fixes."

Right now we support both, because you can run the release branch, or
just cherry-pick and apply the security patches when we release them.
This does mean you're no longer running something that's been tagged
as a release, of course.

So the question, as I see it, is whether we change that around. There
are a couple options:

1. Once we cut X.Y, that's it. The resulting release branch will get
security updates and no other changes. This will support case (2)
above, but not (1).

2. Each release gets *two* branches. One gets full bugfix support, the
other only gets security. This means a security fix results in two new
packages -- one from the full-bugfix branch and one from the
security-only branch, but means people can choose what they want.

I don't think either of these actually works, though; option 1
completely cuts off people who want general bugfix support, and since
that's a valid use case (and one I'm pretty sure people rely on) we
can't do that. Option 2 doesn't cut anybody off, but does create a bit
of a confusing maze of packages -- do I want Django 1.2.5? Django
1.2.4.1? Django 1.2.3.2? This would get worse once a release falls
into security-only mode and it becomes harder to distinguish the
branches from what's going on in them (since they'd both be getting
exactly the same updates at that point). It'd also be a major
maintenance/bookkeeping headache and, I think, *more* likely to result
in us accidentally crossing the streams while trying to keep track of
what goes on in which branch.

Personally, I'd be in favor of keeping the overall release process
as-is -- one release branch, which gets all bugfixes while applicable,
plus highlighting the individual security patches as released -- and
providing better documentation of what the release branch really is
(i.e., not a security-only branch) and how to pull just a security
update if that's what you want.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

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

Re: Regressions in 1.2.4

[Ramiro Morales]

On Wed, Jan 5, 2011 at 1:05 PM, Russell Keith-Magee
 wrote:
>
> We will obviously to do a 1.2.5 release when we hit 1.3 final; but I'm
> not sure if we should push an 1.2.5 (and 1.1.4) ASAP addressing these
> regressions, and then do 1.2.6 when we cut 1.3 final.
>
> This also points out that we should perhaps reconsider our release
> policy. Putting out security releases that include unrelated fixes is
> a bit of a risk. We've been bitten by this in the past, but never this
> bad. I would suggest that when security issues arises in 1.2.3, we
> should be releaseing 1.2.3.1 rather than 1.2.4. If a security release
> coincides with a point release -- as it did when we released 1.3beta1
> -- we should release 1.2.3.1 (to address the security issue) *and*
> 1.2.4 (to get the other bugfixes). This will ensure that it is
> possible to update production code and get just the security fix,
> without any risk of regressions.
>
> Any opinions on these two points?

I agree with getting a 1.2.5 ASAP.

Also, it has always been my thought that the security releases
should contain only the security fix(es) that trigger them,
and always asked myself if it would be too crazy to propose
a four-component A.B.C.D versioning schema.

IT policies that force users to only install releases software
won't allow people to run a 1.2.3 with the security fixes
manually applied over it, and user won't dare to go straight to
e.g. 1.2.4 based on knowledge  of our release policy plus
experience of regressions in other parts of the framework
in security releases.

Data point:

Ubuntu has released these two security fixes for their users
not by packaging 1.2.4 but by creating a 1.2.3-1ubuntu0.2.11.04.1
(talk about long package release numbers) I suspected they
simply applied the patches linked from the announcement.

http://changelogs.ubuntu.com/changelogs/pool/main/p/python-django/python-django_1.2.3-1ubuntu0.2.11.04.1/changelog

The only issue I have with these two yes it that they mean adding
burden to our release manager. But maybe that's topic for another
discussion.

Regards,

-- 
Ramiro Morales

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

Re: Regressions in 1.2.4

[Karen Tracey]

On Wed, Jan 5, 2011 at 11:05 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> This also points out that we should perhaps reconsider our release
> policy. Putting out security releases that include unrelated fixes is
> a bit of a risk. We've been bitten by this in the past, but never this
> bad. I would suggest that when security issues arises in 1.2.3, we
> should be releaseing 1.2.3.1 rather than 1.2.4. If a security release
> coincides with a point release -- as it did when we released 1.3beta1
> -- we should release 1.2.3.1 (to address the security issue) *and*
> 1.2.4 (to get the other bugfixes). This will ensure that it is
> possible to update production code and get just the security fix,
> without any risk of regressions.
>
> Any opinions on these two points?
>

The fact that a "security release" includes other fixes does seem to
regularly surprise people. And best efforts at keeping the maintenance
branch regression-free aren't perfect. So I like the idea of security-only
releases.

I assume we would only release a security-fix-only release for the latest
micro release? So say we had 1.2.3, and as you mention simultaneously
release 1.2.3.1 which is security fix only, plus 1.2.4 which also includes
all the bugs fixed since 1.2.3. Then we get another confirmed security issue
to be fixed. We'd release 1.2.4.1 only, not 1.2.3.2 also?

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

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

Re: i18n bug in template rendering.

[Jonathan S]

Thanks Ramiro, we hope the patch will be applied in the next release.

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

Re: i18n bug in template rendering.

[Ramiro Morales]

On Thu, Jan 6, 2011 at 8:15 AM, Ramiro Morales  wrote:

> Weird, it's working here:

Ignore me, I was creating a new Template instance. I can reproduce it:



In [1]: from django.utils import translation

In [2]: from django.template import Template, Context

In [3]:

In [4]:

In [5]: def language(language_code):
   ...: class with_block(object):
   ...: def __enter__(self):
   ...: self._old_language = translation.get_language()
   ...: translation.activate(language_code)
   ...: def __exit__(self, *args):
   ...: translation.activate(self._old_language)
   ...: return with_block()
   ...:

In [6]: with language('de'): z = Template("{% load i18n %}{{
0|yesno:_('yes,no,maybe') }}")
   ...:

In [7]: with language('nl'):
   ...: z.render(Context())
   ...:
   ...:
Out[7]: u'Nein'

In [8]: with language('en'):
   ...: z.render(Context())
   ...:
   ...:
Out[8]: u'Nein'

If I apply this small fix to our code:

http://paste.pocoo.org/show/315758/

Things work correctly:

In [1]: from django.utils import translation

In [2]: from django.template import Template, Context

In [3]:

In [4]:

In [5]: def language(language_code):
   ...: class with_block(object):
   ...: def __enter__(self):
   ...: self._old_language = translation.get_language()
   ...: translation.activate(language_code)
   ...: def __exit__(self, *args):
   ...: translation.activate(self._old_language)
   ...: return with_block()
   ...:

In [6]: with language('de'): z = Template("{% load i18n %}{{
0|yesno:_('yes,no,maybe') }}")
   ...:

In [7]: with language('nl'):
   ...: z.render(Context())
   ...:
   ...:
Out[7]: u'nee'

In [8]: with language('en'):
   ...: z.render(Context())
   ...:
   ...:
Out[8]: u'no'

and out test suite still runs, but I need to add regression tests.
Will ask about this to I18N maintainers/contributors. Thanks!

-- 
Ramiro Morales

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

Re: i18n bug in template rendering.

[Ramiro Morales]

On Thu, Jan 6, 2011 at 5:07 AM, Jonathan S  wrote:
>
>> You aren't supposed to use _('Foo') as a standalone variable.
>> (see last paragraph 
>> herehttp://docs.djangoproject.com/en/1.2/topics/i18n/internationalization...)
>
>
> Why shouldn't I use it as a standalone variable? (A language should
> have a *context free* grammar, which means, that the underscore
> function can be used in any variable. But that's no problem in
> Django.)
>
>
> That's not the point, the bug applies to any variable, template tag or
> template filter parameter. It seems like a bug to me:
> Any underscore function is translated during the initialisation of the
> template, and that is wrong to me.
>
> I guess, also for this one, like mentioned in the documentation.
> {% some_special_tag _("Page not found") value|yesno:_("yes,no") %}
>
> And I did a quick test:
>
>
> with language('nl'):
>  t = Template("{% load i18n %}{{ 1|yesno:_('yes,no') }}")
>
> t.render(Context()) # Will output 'ja'
> with language('en'):
>  t.render(Context()) # Will still output 'ja', even if the language
> is English now...

Weird, it's working here:

In [1]: from django.utils import translation

In [2]: from django.template import Template, Context

In [3]:

In [4]:

In [5]: def language(language_code):
   ...: class with_block(object):
   ...: def __enter__(self):
   ...: self._old_language = translation.get_language()
   ...: translation.activate(language_code)
   ...: def __exit__(self, *args):
   ...: translation.activate(self._old_language)
   ...: return with_block()
   ...:

In [6]: with language('nl'):
   ...: Template("{% load i18n %}{{ 1|yesno:_('yes,no,maybe')
}}").render(Context())
   ...:
   ...:
Out[6]: u'ja'

In [7]: with language('en'):
Template("{% load i18n %}{{ 1|yesno:_('yes,no,maybe') }}").render(Context())
   ...:
   ...:
Out[7]: u'yes'

In [8]: with language('nl'):
Template("{% load i18n %}{{ 0|yesno:_('yes,no,maybe') }}").render(Context())
   :
   :
Out[8]: u'nee'

In [9]: with language('en'):
Template("{% load i18n %}{{ 0|yesno:_('yes,no,maybe') }}").render(Context())
   :
   :
Out[9]: u'no'

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

Re: ImageField documentation clarification

[Russell Keith-Magee]

On Thu, Jan 6, 2011 at 6:06 PM, James Hancock  wrote:
> I am very new to Django, and so I spend a lot of time in the documentation.
> The other day I found something that I wished would have some more
> clarification in retrospect, so I thought I would post it here.
>
>
> My goal was to have the admin resize an image for me on upload to a standard
> size.
>
> While reading the docs for an Image Fields I saw the "height_field=None,
> width_field=None"  and thought, "oh, if I set this, then It will resize it
> for me." You'll probably all laugh at this point, but that is what I
> thought, and yes it is very wrong. After asking on the rc I was pointed to
> some third party thumbnail apps I could use. to get the functionality I was
> looking for.
>
> To save other new people with the same thought process you could put
> something like, "You can't manually set the image size from the model field.
> To manipulate the image size on upload or in a template view use a third
> party thumbnail application."
>
> The thing that would have saved me is basically, " 'Thumbnail apps' is the
> terminology you are looking for". I would then merrily google my way around
> trying to find one, rather than looking in the documentation.
>
>
> I wouldn't suggest specifically naming apps, effectivly endorsing them
> unless there is a clear choice on one that is always used and well
> maintained. I am to new with Django to determine that.

Sounds like a reasonable suggestion. The best way to make sure this
suggestion isn't forgotten is to open a ticket in Trac with the
details you've provided here.

If you want to be really helpful, try writing a draft of the update
you'd like to see. The docs directory in a source checkout of Django
contains all the raw text; update that text, generate a diff, and
upload the diff to the ticket.

If you need any help on how to do this, don't be afraid to ask, either
here or in IRC.

Yours,
Russ Magee %-)

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

ImageField documentation clarification

[James Hancock]

I am very new to Django, and so I spend a lot of time in the documentation.
The other day I found something that I wished would have some more
clarification in retrospect, so I thought I would post it here.


My goal was to have the admin resize an image for me on upload to a standard
size.

While reading the docs for an Image
FieldsI
saw the
*"height_field=None*, *width_field=None"  *and thought, "oh, if I set this,
then It will resize it for me." You'll probably all laugh at this point, but
that is what I thought, and yes it is very wrong. After asking on the rc I
was pointed to some third party thumbnail apps I could use. to get the
functionality I was looking for.

To save other new people with the same thought process you could put
something like, "You can't manually set the image size from the model field.
To manipulate the image size on upload or in a template view use a third
party thumbnail application."

The thing that would have saved me is basically, " 'Thumbnail apps' is the
terminology you are looking for". I would then merrily google my way around
trying to find one, rather than looking in the documentation.


I wouldn't suggest specifically naming apps, effectivly endorsing them
unless there is a clear choice on one that is always used and well
maintained. I am to new with Django to determine that.


Thanks,
James Hancock
**

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

Re: i18n bug in template rendering.

[Jonathan S]

> You aren't supposed to use _('Foo') as a standalone variable.
> (see last paragraph 
> herehttp://docs.djangoproject.com/en/1.2/topics/i18n/internationalization...)


Why shouldn't I use it as a standalone variable? (A language should
have a *context free* grammar, which means, that the underscore
function can be used in any variable. But that's no problem in
Django.)


That's not the point, the bug applies to any variable, template tag or
template filter parameter. It seems like a bug to me:
Any underscore function is translated during the initialisation of the
template, and that is wrong to me.

I guess, also for this one, like mentioned in the documentation.
{% some_special_tag _("Page not found") value|yesno:_("yes,no") %}

And I did a quick test:


with language('nl'):
 t = Template("{% load i18n %}{{ 1|yesno:_('yes,no') }}")

t.render(Context()) # Will output 'ja'
with language('en'):
  t.render(Context()) # Will still output 'ja', even if the language
is English now...



The underscore, which is a parameter for a template filter, is also
translated during the initialisation of the template...

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