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

2014-11-27 Thread Florian Apolloner


On Thursday, November 27, 2014 9:44:28 PM UTC+1, Shai Berger wrote:
>
> 1) Using the migration name in the index isn't really "predictable", and 
> isn't 
> even completely stable (the name changes when migrations are squashed), 
> unless 
> I'm missing something. 
>

I think squashing isn't an issue, the migration name would get hardcoded 
into the operation as argument and squashing would just have to preserve 
that.

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/fcfdb8dc-72cd-48af-a78a-7c7b9cb4e43f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Adding hard dependencies to Django's test suite

2014-11-27 Thread Fabio Caritas Barrionuevo da Luz
python 2.7.9 rc1 include a backported version of python3 ensurepip

see: 

https://hg.python.org/cpython/rev/592a5414fabd
https://docs.python.org/2/library/ensurepip.html

-- 
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/173434d5-3313-47b6-bfed-07463c58aa8a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Adding hard dependencies to Django's test suite

2014-11-27 Thread Tim Graham
There have been some proposals to add new dependencies in Django's test 
suite:

1. #23289  - unittest.mock 
(included in Python 3.3+; a backport version would need be installed when 
testing on Python 2.7 and 3.2)
2. #23792  - freezegun (to 
freeze time.time() and fix some non-deterministic tests, rather than create 
our own "poor freezegun" utility in django.test)

Our current policy is that all test dependencies are optional and if they 
aren't installed, the test is skipped. I'd like to think that Python 
packaging is mature enough that we could consider adding some "hard 
dependencies" like the above (and perhaps removing the existing skip 
requirement entirely) such that runtests.py would thrown an error if it 
doesn't find any required dependencies rather than continue down the path 
of skipping tests which can be tedious. We have the test dependencies in 
requirements files (see tests/requirements) so installing the dependencies 
is fairly painless using pip.

While I know the idea that you can simply clone Django and run the tests 
straight away is appealing, I believe the fact that Python 3.4 includes pip 
and virtualenv should allow us to move forward here. If this nudges people 
to contribute to Django using Python 3 in their local environment, I'd 
consider that a win. If the Django Girls tutorial can use Python 3 (albeit 
with the help of a coach), I'd think Django's contributing docs could take 
this approach as well.

What do you think?

-- 
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/df1b45c7-55e7-4d56-b4fa-763a211fdb5a%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-27 Thread Shai Berger
Hi,

Just noted this thread, and I have two points:

1) Using the migration name in the index isn't really "predictable", and isn't 
even completely stable (the name changes when migrations are squashed), unless 
I'm missing something.

2) The current practice of identifying indexes by the columns they use is 
sufficient now, but may not suffice when we have finer control over indexes 
(Marc 
Tamlyn is writing the DEP[1] for this). I can very easily see, for example, 
uses for two partial indexes on the same field (on PG, where partial indexes 
exist).

I'm not sure we need fully predictable index names now, but my hunch is that 
we are going to need them down the road, and an explicitly-set suffix is a lot 
closer to what we'll need than a random one.

My 2 cents,
Shai.


[1] https://github.com/django/deps/pull/6/files


Re: Infinite loop in migration code

2014-11-27 Thread Markus Holtermann
Hey Luke,

I cannot reproduce your problem on neither master nor stable/1.7.x. When I 
run "python manage.py makemigrations camps" the migrations for the 
"officers" app are also generated (as I expect it). "testapp" is your 
"camps" app, "otherapp" is your "officers" app: 
https://gist.github.com/MarkusH/d84618db929fd6fcdb9f

The dependencies look fine to me, and migrating works like a charm. I also 
tried both the string representation 'auth.User' and importing d.c.a.m.User 
and using the class reference in the FK fields, but that doesn't make any 
difference.

If you can reproduce the issue, could you please push a sample project to 
GitHub. I'm happy to look into it then.

/Markus

On Thursday, November 27, 2014 5:20:52 PM UTC+1, Luke Plant wrote:
>
> Hi Markus, 
>
>
> It was basically this: 
>
> == app camps == 
>
> class Camp: 
>
>   invited_officers = M2M(auth.User, through='officers.Invitation') 
>
>
> == app officers == 
>
> class Invitation: 
>   timestamp = models.DateTimeField(default=datetime.now) 
>   camp = FK(camps.Camp) 
>   user = FK(auth.User) 
>
>
> = 
>
> I ran makemigrations for 'camps', then 'officers', and the generated 
> migrations ended up depending on each other. 
>
> Hopefully that's enough, let me know if that doesn't reproduce it. 
> Sorry, don't have time to put it together more formally. 
>
> Thanks, 
>
> Luke 
>
>
> On 26/11/14 13:08, Markus Holtermann wrote: 
> > Can you open a ticket with your models so the issue doesn't get lost. 
> > I'm happy to work on it. 
> > 
> > Although it's somewhat uncommon, people normally have the through model 
> > in the app that has the m2m field (why don't you define it on the other 
> > model?) this is still something that shouldn't happen. 
> > 
> > /Markus 
> > 
> > On Wednesday, November 26, 2014 8:54:55 AM UTC+1, Luke Plant wrote: 
> > 
> > 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/ 
>
>
> -- 
> "In your presence there is fullness of joy; at your right hand are 
> pleasures forevermore" Psalm 16:11 
>
> 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/83263507-d328-4b6e-95d6-e8a2e9d557f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Infinite loop in migration code

2014-11-27 Thread Luke Plant
Hi Markus,


It was basically this:

== app camps ==

class Camp:

  invited_officers = M2M(auth.User, through='officers.Invitation')


== app officers ==

class Invitation:
  timestamp = models.DateTimeField(default=datetime.now)
  camp = FK(camps.Camp)
  user = FK(auth.User)


=

I ran makemigrations for 'camps', then 'officers', and the generated
migrations ended up depending on each other.

Hopefully that's enough, let me know if that doesn't reproduce it.
Sorry, don't have time to put it together more formally.

Thanks,

Luke


On 26/11/14 13:08, Markus Holtermann wrote:
> Can you open a ticket with your models so the issue doesn't get lost.
> I'm happy to work on it.
> 
> Although it's somewhat uncommon, people normally have the through model
> in the app that has the m2m field (why don't you define it on the other
> model?) this is still something that shouldn't happen.
> 
> /Markus
> 
> On Wednesday, November 26, 2014 8:54:55 AM UTC+1, Luke Plant wrote:
> 
> 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/f2924e77-7604-4632-a7c1-1920a3bfb4d0%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.


-- 
"In your presence there is fullness of joy; at your right hand are
pleasures forevermore" Psalm 16:11

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/54774F2E.2020306%40cantab.net.
For more options, visit https://groups.google.com/d/optout.