Fixing #10811 Prevet assigning of unsaved model to Foreign Key

2014-01-24 Thread anubhav joshi
I have tried fixiing #10811 https://code.djangoproject.com/ticket/10811

Earlier there were several errors popping up while running the test suite, 
but now I have fixed most of them.
Although there are 2 errors which  I am unable to fix some of them as I am 
unable to understand what the code is doing there.
Need help here..

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

-- 
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/ad8f57f5-4365-417d-b783-66c6392df4d4%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Quick question re typo-fixing etiquette

2014-01-24 Thread James Turley
Great, thanks.

On Friday, January 24, 2014 3:35:14 PM UTC, Tim Graham wrote:
>
> Any logical grouping like "Fixed bad apostrophes" or "Fixed grammar errors 
> in docs/index.txt" would be acceptable. We definitely don't want a PR for 
> every individual correction as that'll just clutter the commit history. 
> Thanks!
>
> On Friday, January 24, 2014 9:21:10 AM UTC-5, gilberto dos santos alves 
> wrote:
>>
>> please see faq at [1] or [2]
>>
>> [1] https://docs.djangoproject.com/en/1.6/faq/
>> [2] irc://irc.freenode.net/django
>>
>>
>> 2014/1/24 James Turley 
>>
>>> Hi all,
>>>
>>> I'm a relatively novice Pythonist, but a hardened and incorrigible 
>>> spelling/grammar pedant, so I feel I could contribute in some small way by 
>>> fixing language errors in the docs as required.
>>>
>>> In the submitting patches guide, it says: "If you are fixing a really 
>>> trivial issue, for example changing a word in the documentation, the 
>>> preferred way to provide the patch is using GitHub pull requests without a 
>>> Trac ticket. Trac tickets are still acceptable." That's fine. My question 
>>> is: how 'trivial' should each pull request be? Should I make one for each 
>>> file I go through, or one for every last stray apostrophe, or something 
>>> else? I don't want to flood the committers with hundreds of meaningless 
>>> typo fixes and grammar corrections, at least if that's not the done thing.
>>>
>>> Thanks
>>> James 
>>>
>>> -- 
>>> 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@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/b394cfd0-09ff-4409-972f-a688171580ef%40googlegroups.com
>>> .
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>
>>
>> -- 
>> gilberto dos santos alves
>> +55.11.98646-5049
>> sao paulo - sp - brasil
>>
>>
>>
>>
>>  

-- 
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/781b1837-3ff6-4b78-a40b-70a46d3aebe9%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Quick question re typo-fixing etiquette

2014-01-24 Thread Tim Graham
Any logical grouping like "Fixed bad apostrophes" or "Fixed grammar errors 
in docs/index.txt" would be acceptable. We definitely don't want a PR for 
every individual correction as that'll just clutter the commit history. 
Thanks!

On Friday, January 24, 2014 9:21:10 AM UTC-5, gilberto dos santos alves 
wrote:
>
> please see faq at [1] or [2]
>
> [1] https://docs.djangoproject.com/en/1.6/faq/
> [2] irc://irc.freenode.net/django
>
>
> 2014/1/24 James Turley 
>
>> Hi all,
>>
>> I'm a relatively novice Pythonist, but a hardened and incorrigible 
>> spelling/grammar pedant, so I feel I could contribute in some small way by 
>> fixing language errors in the docs as required.
>>
>> In the submitting patches guide, it says: "If you are fixing a really 
>> trivial issue, for example changing a word in the documentation, the 
>> preferred way to provide the patch is using GitHub pull requests without a 
>> Trac ticket. Trac tickets are still acceptable." That's fine. My question 
>> is: how 'trivial' should each pull request be? Should I make one for each 
>> file I go through, or one for every last stray apostrophe, or something 
>> else? I don't want to flood the committers with hundreds of meaningless 
>> typo fixes and grammar corrections, at least if that's not the done thing.
>>
>> Thanks
>> James 
>>
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@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/b394cfd0-09ff-4409-972f-a688171580ef%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> -- 
> gilberto dos santos alves
> +55.11.98646-5049
> sao paulo - sp - brasil
>
>
>
>
>  

-- 
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/d2a7d643-cd7e-40e8-8e17-1360272b3743%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: 1.7 Schema migrations and AUTH_PROFILE_MODULE / get_profile() deprecation

2014-01-24 Thread Brian Neal
Dear All:

After reading this discussion I see that my fears were misplaced. I can now 
see that schema migrations are not necessary to stop using the AUTH_PROFILE 
stuff thanks to the explanations from Russ and Carl. Had I done a bit more 
investigating I probably would have realized this. Sorry for the noise.

If Django wants help to add a note to the docs about this perhaps I can 
help with that. I suspect a few people might be scared about this change (I 
was).

Best,
BN

-- 
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/14129585-ee91-4199-899c-532fefd7730a%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Quick question re typo-fixing etiquette

2014-01-24 Thread gilberto dos santos alves
please see faq at [1] or [2]

[1] https://docs.djangoproject.com/en/1.6/faq/
[2] irc://irc.freenode.net/django


2014/1/24 James Turley 

> Hi all,
>
> I'm a relatively novice Pythonist, but a hardened and incorrigible
> spelling/grammar pedant, so I feel I could contribute in some small way by
> fixing language errors in the docs as required.
>
> In the submitting patches guide, it says: "If you are fixing a really
> trivial issue, for example changing a word in the documentation, the
> preferred way to provide the patch is using GitHub pull requests without a
> Trac ticket. Trac tickets are still acceptable." That's fine. My question
> is: how 'trivial' should each pull request be? Should I make one for each
> file I go through, or one for every last stray apostrophe, or something
> else? I don't want to flood the committers with hundreds of meaningless
> typo fixes and grammar corrections, at least if that's not the done thing.
>
> Thanks
> James
>
> --
> 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/b394cfd0-09ff-4409-972f-a688171580ef%40googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
gilberto dos santos alves
+55.11.98646-5049
sao paulo - sp - brasil

-- 
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/CAP9G-NK6P9dDKNc3J_9et7LSRaBaudUDOU2S7dCX%2BByXQUPfjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


Quick question re typo-fixing etiquette

2014-01-24 Thread James Turley
Hi all,

I'm a relatively novice Pythonist, but a hardened and incorrigible 
spelling/grammar pedant, so I feel I could contribute in some small way by 
fixing language errors in the docs as required.

In the submitting patches guide, it says: "If you are fixing a really 
trivial issue, for example changing a word in the documentation, the 
preferred way to provide the patch is using GitHub pull requests without a 
Trac ticket. Trac tickets are still acceptable." That's fine. My question 
is: how 'trivial' should each pull request be? Should I make one for each 
file I go through, or one for every last stray apostrophe, or something 
else? I don't want to flood the committers with hundreds of meaningless 
typo fixes and grammar corrections, at least if that's not the done thing.

Thanks
James 

-- 
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/b394cfd0-09ff-4409-972f-a688171580ef%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: 1.7 Schema migrations and AUTH_PROFILE_MODULE / get_profile() deprecation

2014-01-24 Thread Ryan Hiebert
On Thu, Jan 23, 2014 at 11:25 PM, Carl Meyer  wrote:

> Hi Ryan,
>
> On 01/23/2014 09:50 PM, Ryan Hiebert wrote:
> > Assuming that the changes from the deprecation policy are in trunk now
> > that the alpha has landed, any use of the AUTH_PROFILE_MODULE must be
> > eliminated _before_ moving to 1.7, since they are not just deprecated,
> > but _removed_ in 1.7. Migrating to 1.7 will _break_ code that uses it.
> > This is normal and expected.
> >
> > Since the new migration system lands in 1.7, and AUTH_PROFILE_MODULE is
> > removed in 1.7, then it is clear that it won't be possible to use the
> > new migration system to do the custom migrations that may be required to
> > stop using the AUTH_PROFILE_MODULE.
>
> I think this is the point of confusion. No migrations are required to
> stop using AUTH_PROFILE_MODULE, since the AUTH_PROFILE_MODULE feature
> does not affect the database in any way, it simply changes (very
> slightly) the code you use to access the database.
>
> If you have a Profile model in an "accounts" app, and you have
> AUTH_PROFILE_MODULE set to "accounts.Profile", here are the sum total of
> steps needed to stop using AUTH_PROFILE_MODULE:
>
> 1. Remove the AUTH_PROFILE_MODULE setting.
>
> 2. Replace occurrences of "user.get_profile()" in your code with
> "user.profile".
>
> Note the lack of any database migrations in those steps.
>
> > Allowing one more release before AUTH_PROFILE_MODULE is removed would
> > allow him to use the new migration system to create a custom migration
> > to migrate away from using the profiles. Otherwise, he'd need to use
> > South or go through two code change cycles.
>
> You are correct that _if_ you should happen to _also_ want to move the
> data you are storing in the Profile table to somewhere else, you won't
> be able to do that using a Django 1.7 migration at the exact same time
> as you remove the occurrences of "user.get_profile()" in your code. But
> there's no particular reason the removal of AUTH_PROFILE_MODULE should
> make you want to move data out of the Profile table, unless it just
> happened to remind you that you'd been wanting to do that anyway.
>
> So I think in a sense you and Russell are both right :-) But I don't
> think there's a strong enough case here to justify extending the
> lifetime of AUTH_PROFILE_MODULE. There's no harm in changing
> "user.get_profile()" to "user.profile" right now, and then waiting until
> 1.7 to do your migration. Or if you really want to do them in a single
> change to your codebase, you just do it now under Django 1.5 or 1.6
> using South.
>

Thanks Carl. I suspected that the code migration is seen as a small enough
issue not to warrant keeping get_profile() around, thanks for understanding
and answering that specifically. I think that's what the OP was all about,
and I wanted to make sure we all understood the tradeoff.

I personally use South, so this is not any issue for me, but I understand
the use case being presented.

-- 
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/CABpHFHSjS8S85e12kayTVmc-Jz2H9x0hVo4EgnkmOTqF7J5gRg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.