Re: Migrations in Django 1.7 make unit testing models harder

2014-03-28 Thread Bernie Sumption
The problem with --update is that if overwrites the most recent migration, 
then it might be used to modify a committed and distributed migration, 
which is a Bad Thing. The flag would probably be useful to people with my 
use case, if they trust themselves to use the flag with care and remember 
to not use it immediately after committing. Was this the reason that you 
didn't carry --update from South to Django?

Entertainingly, I was about to defend my original proposal, but have just 
realised that for the last few days while we've been having this 
conversation, I have not been remembering to run makemigrations before 
committing, thereby falling into exactly the trap that you predicted my 
behaviour would produce!

Given that --update and my original proposal both have significant dangers 
if not used properly, my new thought is to write a "safe update migrations" 
script that used Git to delete all uncommitted migrations and runs 
makemigrations again. This could give me the best of both worlds - tests 
that "just work", no build up of many tiny migrations files, and no risk of 
trashing the committed migration history.

I'm coming to think that there's no change that could be made to Django 
core that would magically fix this without side effects, so perhaps it 
should be left to the community to create and share scripts that work for 
each VCS?

Bernie :o)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/99a6263a-f720-481e-a9b5-4714eb960019%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Migrations in Django 1.7 make unit testing models harder

2014-03-28 Thread Bernie Sumption
OK, it turns out that the "safe update migrations script" too simple to 
even qualify as a "script":

git clean myapp/migrations -f && python manage.py makemigrations

Perhaps the solution is to document this on the testing page as a solution 
to the "accumulation of many small migrations during development" problem?

Bernie :o)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/e15603d7-ed14-4d18-b36b-925aaf824bce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Migrations in Django 1.7 make unit testing models harder

2014-03-28 Thread Marc Tamlyn
That script would be bad if you'd run any of those migrations against your
development db (yes it should be "throwaway" or rebuildable but...)

Personally, I'm strongly in favour of Shai's suggestion and also in favour
of --update, mainly as I like being able to capture (most) migrations has
logical bits of work as it aids code review. My pull requests don't include
every iteration of the code I wrote to get the final version, so why should
my migrations?

M


On 28 March 2014 10:13, Bernie Sumption  wrote:

> OK, it turns out that the "safe update migrations script" too simple to
> even qualify as a "script":
>
> git clean myapp/migrations -f && python manage.py makemigrations
>
> Perhaps the solution is to document this on the testing page as a solution
> to the "accumulation of many small migrations during development" problem?
>
> Bernie :o)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/e15603d7-ed14-4d18-b36b-925aaf824bce%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" 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/CAMwjO1GHc4KtnmEs%3DuWQV8YP0OzRQ61YFo2ZFuJurrE%3DsVsghw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Migrations in Django 1.7 make unit testing models harder

2014-03-28 Thread Bernie Sumption


> That script would be bad if you'd run any of those migrations against your 
> development db (yes it should be "throwaway" or rebuildable but...)
>

I'd think the same could be said of --update? As I understand it, --update 
is the equivalent of deleting the most recent migration and recreating it. 
If you'd applied the most recent migration to your development database and 
then you --update that migration, you'd need to rebuild the database.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/f3e1b67b-f1fc-4c94-964f-23ec7fb27755%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Migrations in Django 1.7 make unit testing models harder

2014-03-28 Thread Marc Tamlyn
South's `--update` also rolled the previous migration back, changed it and
then reapplied it to the current database.

M


On 28 March 2014 10:48, Bernie Sumption  wrote:

>
> That script would be bad if you'd run any of those migrations against your
>> development db (yes it should be "throwaway" or rebuildable but...)
>>
>
> I'd think the same could be said of --update? As I understand it, --update
> is the equivalent of deleting the most recent migration and recreating it.
> If you'd applied the most recent migration to your development database and
> then you --update that migration, you'd need to rebuild the database.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/f3e1b67b-f1fc-4c94-964f-23ec7fb27755%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" 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/CAMwjO1Gw5efPyC%2BFH%2BzEvXeW2p_6z-JkqbVUScrvtyXAJmmK6A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Migrations in Django 1.7 make unit testing models harder

2014-03-28 Thread Bernie Sumption

>
> South's `--update` also rolled the previous migration back, changed it and 
> then reapplied it to the current database.
>

OK, in that case I can very much see how it's useful for people who develop 
against a persistent database. That's probably most people.

Anyway, the result of this thread for me is that I now consider my original 
request to be obsolete, as the "git clean" thing is a simple way of getting 
the behaviour I want for my own style of TDD without hacks.

Thanks for your time.

Bernie :o)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/8e3ecf3c-aa05-4e3d-b905-3260b093e046%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Migrations in Django 1.7 make unit testing models harder

2014-03-28 Thread Andrew Godwin
Yes, --update is very risky if you run it on migrations that are already
committed and pushed, but the main reason I left it out of 1.7 was
complexity (because makemigrations is now much more intelligent, updating
and adding a foreignkey into a migration might introduce a new dependency
or force a new migration anyway). Given that we have the ability to safely
squash large numbers of small migrations down into one with
squashmigrations and distribute that to fix the many-small-migrations
problem, I considered it pretty low priority, though I have a rough idea of
how I could make it work (I'd have to load up the autodetector with the
existing migrations already loaded in as a halfway state and then run it
from there, which should produce the right result).

Anyway, if you're retracting your original request, I'm happy to leave this
for the 1.7 release; I don't think there's a good solution that Django core
can implement effectively. This reminds me of when people used to ask me to
automatically stop their developers writing conflicting migrations - the
solution varies from company to company and often isn't technical but just
education or communication.

Andrew


On Fri, Mar 28, 2014 at 4:46 AM, Bernie Sumption wrote:

> South's `--update` also rolled the previous migration back, changed it and
>> then reapplied it to the current database.
>>
>
> OK, in that case I can very much see how it's useful for people who
> develop against a persistent database. That's probably most people.
>
> Anyway, the result of this thread for me is that I now consider my
> original request to be obsolete, as the "git clean" thing is a simple way
> of getting the behaviour I want for my own style of TDD without hacks.
>
> Thanks for your time.
>
> Bernie :o)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/8e3ecf3c-aa05-4e3d-b905-3260b093e046%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" 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/CAFwN1upQUB9yAUCs5d__U4BNWj38o4qB-caWg7MCNjFa_39x8w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


PyCon 2014 Sprints

2014-03-28 Thread bendavis78
I know Django will be sprinting at PyCon, and I thought I might like to 
participate. I haven't done conference sprints before, so I'm curious, 
what's the process? If I have a particular ticket that I'm interested in, 
do I just work on that bug at the sprint? Or will there be a proposed list 
of bugs that we will be working on?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/ec0cc8d3-ec3f-469a-b24e-e824d0358d5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Add support for get_or_none?

2014-03-28 Thread Aymeric Augustin
Hello,

I'm not sure this thread is going anywhere and I don't care either way.
If you've been reading up to this point...

... either you have too much spare time. Rather than rehashing this debate,
may I suggest triaging some tickets? That would really help!

https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/
https://code.djangoproject.com/query?status=!closed&stage=Unreviewed&desc=1&order=changetime

... or you really want this feature badly. I'll just leave this here:

from django.db.models.query import QuerySet
from django.db.models.manager import Manager

def queryset_get_or_none(self, *args, **kwargs):
try:
return self.get(*args, **kwargs)
except self.model.DoesNotExist:
pass

QuerySet.get_or_none = queryset_get_or_none

def manager_get_or_none(self, *args, **kwargs):
return self.get_queryset().get_or_none(*args, **kwargs)

Manager.get_or_none = manager_get_or_none

(That kind of monkey-patching isn't the worst because even if
Django grows a method with that name, it will behave the same.)

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/9AE24931-1E65-44C4-808E-AFD232B697C7%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.


Re: PyCon 2014 Sprints

2014-03-28 Thread Aymeric Augustin
Hello,

There's no particular process. Just show up, pick a ticket you're interested 
in, assign it to yourself, and figure out a resolution. Rinse, repeat ;-)

I would simply advise to setup a development environment in advance. Check out 
the source and make sure you can run the tests. That's all!

-- 
Aymeric.



On 28 mars 2014, at 21:39, bendavis78  wrote:

> I know Django will be sprinting at PyCon, and I thought I might like to 
> participate. I haven't done conference sprints before, so I'm curious, what's 
> the process? If I have a particular ticket that I'm interested in, do I just 
> work on that bug at the sprint? Or will there be a proposed list of bugs that 
> we will be working on?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" 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/ec0cc8d3-ec3f-469a-b24e-e824d0358d5f%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" 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/A55F24AD-A4B4-4FC7-A892-301F6A2A%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.


Re: Add support for get_or_none?

2014-03-28 Thread Cal Leeming [Simplicity Media Ltd]
So is that a "no" to the docs patch proposal?

Cal


On Fri, Mar 28, 2014 at 8:52 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> I'm not sure this thread is going anywhere and I don't care either way.
> If you've been reading up to this point...
>
> ... either you have too much spare time. Rather than rehashing this debate,
> may I suggest triaging some tickets? That would really help!
>
>
> https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/
>
> https://code.djangoproject.com/query?status=!closed&stage=Unreviewed&desc=1&order=changetime
>
> ... or you really want this feature badly. I'll just leave this here:
>
> from django.db.models.query import QuerySet
> from django.db.models.manager import Manager
>
> def queryset_get_or_none(self, *args, **kwargs):
> try:
> return self.get(*args, **kwargs)
> except self.model.DoesNotExist:
> pass
>
> QuerySet.get_or_none = queryset_get_or_none
>
> def manager_get_or_none(self, *args, **kwargs):
> return self.get_queryset().get_or_none(*args, **kwargs)
>
> Manager.get_or_none = manager_get_or_none
>
> (That kind of monkey-patching isn't the worst because even if
> Django grows a method with that name, it will behave the same.)
>
> --
> Aymeric.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/9AE24931-1E65-44C4-808E-AFD232B697C7%40polytechnique.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CAHKQagHAWXK3MZh152SBywh8gY6wF7Cb4o230qZoavqdvOw%2BTQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Add support for get_or_none?

2014-03-28 Thread Aymeric Augustin
On 28 mars 2014, at 22:28, Cal Leeming [Simplicity Media Ltd] 
 wrote:

> So is that a "no" to the docs patch proposal?

It isn't. Like I said, I really don't care. If someone wants to commit 
something, that's fine.

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/F8FA7A7F-2A4C-4745-9CD9-E8D329ED39F8%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.


Re: Add support for get_or_none?

2014-03-28 Thread Cal Leeming [Simplicity Media Ltd]
Okay great, I'll send a docs patch in next week (assuming no one shows any
disagreement), and hopefully that'll be the end of it!

Thanks to all for your feedback.

Cal


On Fri, Mar 28, 2014 at 10:04 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> On 28 mars 2014, at 22:28, Cal Leeming [Simplicity Media Ltd] <
> cal.leem...@simplicitymedialtd.co.uk> wrote:
>
> > So is that a "no" to the docs patch proposal?
>
> It isn't. Like I said, I really don't care. If someone wants to commit
> something, that's fine.
>
> --
> Aymeric.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/F8FA7A7F-2A4C-4745-9CD9-E8D329ED39F8%40polytechnique.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CAHKQagHByFK69uJfPvCPpf87wwoVwykX-bL9nEA7KQgoC3m%3D6w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.