Re: Infinite loop in migration code

2014-11-25 Thread Luke Plant
On 25/11/14 16:23, Markus Holtermann wrote:
> Hey Luke,
> 
> It would be interesting to see why A.1 and B.1 depend on each other. If
> there are e.g. FK constraints pointing to models in the other app the
> autodetector should end up with e.g. A.1 <-- B.1 <-- B.2 <-- A.2 (or
> optimized A.1 <-- B.1 <-- A.2), in which case you wouldn't end up with a
> cycle. C.1 would then depend on B.2 (B.1 respectively in the optimized
> graph).

I didn't realise the autodetector could handle that. Looking more
closely, it looks like I have more of an edge case:

App B has a model with a FK to a model in app A

App A has a model with a ManyToMany field 'through' a model in app B.
(It's actually added that way for the sake of the admin for the models
in app A).

So it isn't the straight-forward A has FK to B. It might not be worth
fixing the autodetector for this, as fixing the migrations is relatively
easy. But I think fixing the infinite loop is another matter, and I'll
go ahead and backport that.

Thanks for the input,

Luke


-- 
"We may not return the affection of those who like us, but we
always respect their good judgement." -- Libbie Fudim

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5475873E.3010805%40cantab.net.
For more options, visit https://groups.google.com/d/optout.


Re: does django-admin need a man page?

2014-11-25 Thread Aymeric Augustin
Le 26 nov. 2014 à 01:51, Nick Phillips  a écrit :
> 
> I'd suggest considering implementing
> something to generate a man page from whatever you wish the "canonical"
> source of the information to be.

The canonical source of information is:
https://docs.djangoproject.com/en/dev/ref/django-admin/

Does a rst-->man conversion tool exist?

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4D909BC0-48D2-4064-B8EC-8B70903F2474%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.


Re: does django-admin need a man page?

2014-11-25 Thread Nick Phillips
On Mon, 2014-11-24 at 16:44 -0800, Tim Graham wrote: 
> I raised the issue in #23903 and Aymeric mentioned that it may be
> useful for downstream packagers, e.g. Debian. I installed
> python-django via apt-get on Ubuntu 14.04 and confirmed the existence
> of the man page. I'd like to remove it though (or make it point people
> to 'django-admin --help') as it's out-of-date and 'django-admin
> --help' provides the same information in a much easier to maintain
> format. Does anyone else have input on this?
> 

As far as Debian is concerned, not having a manpage for an executable
installed in the standard path is a bug. So if you don't provide one,
one will probably be written for Debian anyway, albeit not a
particularly good one.

However, as Ben pointed out, "man foo" is the standard interface to
getting long-format information on the "foo" command, if not always the
full docs (g info gr). So I'd suggest considering implementing
something to generate a man page from whatever you wish the "canonical"
source of the information to be.


Cheers,


Nick
-- 
Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195
# These statements are mine, not those of the University of Otago

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1416963109.6414.18.camel%40otago.ac.nz.
For more options, visit https://groups.google.com/d/optout.


review request for anyone who likes regular expression (increasing URLs accepted by URLValidator)

2014-11-25 Thread Tim Graham
Danilo Bargen has done some work to expand the types of URLs accepted by 
URLValidator. His patch adds support for IPv6 addresses, unicode domains, 
and URLs containing authentication data. This has increased the complexity 
of the regular expression quite a bit and I would appreciate if any experts 
in this area could review the pull request.

https://github.com/django/django/pull/2873

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c197df45-86a5-4750-8af4-775c4d9f800c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

2014-11-25 Thread tomv
So one option as you suggest Carl, is to pass a hard coded string into the 
Operation when it's instantiated in the user's migration file. I've taken a 
similar approach, starting one level lower, injecting the migration name 
into database_forwards methods. 
https://github.com/tomviner/django/compare/ticket_23577_with_poc_migration_name_fix

This then passing into schema_editor public method calls (create_model, 
add_field and alter_field, which all need their signatures changed over 
BaseDatabaseSchemaEditor and all the database specific schema editor 
backends). Then the migration name is passed through internal schema editor 
methods like _alter_field, _create_unique_sql, _create_index_sql, 
_create_fk_sql and finally on to _create_index_name.

See how the tests have to pass in extra_index_suffix='schema_test.000x' as 
they don't go through an actual migration file.

To sum up this solution: it's not localised and it's not pretty. I'm sure 
it could be tidied up a little, but unless it can be collapsed to a much 
smaller patch, I'd say having deterministic index names isn't worth the 
impact.


Instead, I propose the following solution: a random string injected into 
the formation of all index names. A much more localised patch: 
https://github.com/tomviner/django/compare/ticket_23577_with_poc_random_string_fix

So final call for examples where having predictable index names matter!

One thing I'm still looking at, regardless of the solution chosen, is 
whether we need to include spatial indexes too.

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/96b5254c-ce27-481e-9087-d655cedf3a02%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Infinite loop in migration code

2014-11-25 Thread Andrew Godwin
Hi Luke,

That was already a fix for infinite looping on the previous iteration that
I committed at the DUTH sprints, but your fix looks more understandable and
cleaner, so I say commit it for sure.

As for backporting - I think we should, as this is potentially a crash bug
(though not a data loss bug) and it's a pretty small thing to backport
anyway.

Andrew


On Tue, Nov 25, 2014 at 8:23 AM, Markus Holtermann  wrote:

> Hey Luke,
>
> It would be interesting to see why A.1 and B.1 depend on each other. If
> there are e.g. FK constraints pointing to models in the other app the
> autodetector should end up with e.g. A.1 <-- B.1 <-- B.2 <-- A.2 (or
> optimized A.1 <-- B.1 <-- A.2), in which case you wouldn't end up with a
> cycle. C.1 would then depend on B.2 (B.1 respectively in the optimized
> graph).
>
> /Markus
>
>
> On Tuesday, November 25, 2014 4:49:22 PM UTC+1, Luke Plant wrote:
>>
>>
>> I came across a bug with an infinite loop in migration dependency
>> searching code. This is fixed here:
>>
>> https://github.com/django/django/commit/ff3d746e8d8e8fbe6de287bd0f4c3a
>> 9fa23c18dc
>>
>> (another person reviewing it would be good, though I think it is
>> correct).
>>
>> My question is, should we backport this to 1.7.x? For me, the bug
>> manifested itself with migrations that were automatically created by
>> Django itself, in a project with apps A, B, and C:
>>
>> App B depends on app A
>> App A depends on app B (it didn't initially, but does now)
>> App C depends on one/both of them.
>>
>> After doing makemigrations for A and B, makemigrations for C then went
>> into an infinite loop.
>>
>> So this is not a really obscure case, and could affect a fair number of
>> people attempting to upgrade to Django 1.7, as I was.
>>
>> Regards,
>>
>> Luke
>>
>>
>> --
>> "We may not return the affection of those who like us, but we
>> always respect their good judgement." -- Libbie Fudim
>>
>> Luke Plant || http://lukeplant.me.uk/
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/5e547550-1002-4a6b-82f0-a8dc7e3ed2b0%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 developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1uq3zkayXL8%3D1QtGpY8hZcYwC64VRXL%2BEXPC6c9nH%3Dawwg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Infinite loop in migration code

2014-11-25 Thread Markus Holtermann
Hey Luke,

It would be interesting to see why A.1 and B.1 depend on each other. If 
there are e.g. FK constraints pointing to models in the other app the 
autodetector should end up with e.g. A.1 <-- B.1 <-- B.2 <-- A.2 (or 
optimized A.1 <-- B.1 <-- A.2), in which case you wouldn't end up with a 
cycle. C.1 would then depend on B.2 (B.1 respectively in the optimized 
graph).

/Markus

On Tuesday, November 25, 2014 4:49:22 PM UTC+1, Luke Plant wrote:
>
>
> I came across a bug with an infinite loop in migration dependency 
> searching code. This is fixed here: 
>
>
> https://github.com/django/django/commit/ff3d746e8d8e8fbe6de287bd0f4c3a9fa23c18dc
>  
>
> (another person reviewing it would be good, though I think it is correct). 
>
> My question is, should we backport this to 1.7.x? For me, the bug 
> manifested itself with migrations that were automatically created by 
> Django itself, in a project with apps A, B, and C: 
>
> App B depends on app A 
> App A depends on app B (it didn't initially, but does now) 
> App C depends on one/both of them. 
>
> After doing makemigrations for A and B, makemigrations for C then went 
> into an infinite loop. 
>
> So this is not a really obscure case, and could affect a fair number of 
> people attempting to upgrade to Django 1.7, as I was. 
>
> Regards, 
>
> Luke 
>
>
> -- 
> "We may not return the affection of those who like us, but we 
> always respect their good judgement." -- Libbie Fudim 
>
> Luke Plant || http://lukeplant.me.uk/ 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5e547550-1002-4a6b-82f0-a8dc7e3ed2b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Infinite loop in migration code

2014-11-25 Thread Luke Plant

I came across a bug with an infinite loop in migration dependency
searching code. This is fixed here:

https://github.com/django/django/commit/ff3d746e8d8e8fbe6de287bd0f4c3a9fa23c18dc

(another person reviewing it would be good, though I think it is correct).

My question is, should we backport this to 1.7.x? For me, the bug
manifested itself with migrations that were automatically created by
Django itself, in a project with apps A, B, and C:

App B depends on app A
App A depends on app B (it didn't initially, but does now)
App C depends on one/both of them.

After doing makemigrations for A and B, makemigrations for C then went
into an infinite loop.

So this is not a really obscure case, and could affect a fair number of
people attempting to upgrade to Django 1.7, as I was.

Regards,

Luke


-- 
"We may not return the affection of those who like us, but we
always respect their good judgement." -- Libbie Fudim

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5474A4F1.20208%40cantab.net.
For more options, visit https://groups.google.com/d/optout.


Re: Configurable safety options for high performance Django systems

2014-11-25 Thread Florian Apolloner


On Monday, November 24, 2014 10:05:47 PM UTC+1, Rick van Hattem wrote:
>
> My goal was simply to move the Django project forward but it seems the 
> problems I've encountered in the field are too uncommon for most other 
> developers to care or understand.
>

Oh, I can assure you that we care and understand (and you are certainly not 
the only one with a somewhat big site), but in the end I think the 
arguments against it as shown by Christophe outweigh what you are 
proposing. That said, I still fail to see the issue, set a memory limit for 
your apps (man ulimit) and you get a nice MemoryError when libpq tries to 
overallocate -- including a nice traceback… Adding security guards for any 
ill written application is not going to fly (especially if it's not as easy 
as adding a LIMIT which has it's own problems as pointed out), sorry.

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6fa16884-b69c-494b-b795-f6fa4aa24c14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.