Re: Improving MSSQL and Azure SQL support on Django

[Vin Yu]

Hey Folks,

My name is Vin and I work with Meet in the Microsoft SQL Server team. Just 
wanted to let you all know we are still looking into how we can better improve 
and support MSSQL for the Django framework. We’ll continue to sync with Michael 
and let you know of any updates soon. 

Christiano and Tim - thanks for sharing your interest and sharing how you are 
using Django with MSSQL. It's great to learn from your scenarios.

If you have any concerns, questions or comments feel free to reach out to me at 
vinsonyu[at]microsoft.com

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/19995339-c5cd-4db6-9ca5-8fe550438310%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Markus Holtermann]

Cheers Tim,

looks good to me, assuming the migration actually works :-], haven't tried 
it out. We probably should advice people that running that migration 
potentially takes a while, depending on how many passwords they need to 
update.

/Markus

On Friday, February 19, 2016 at 3:52:53 AM UTC+11, Tim Graham wrote:
>
> Feedback is welcome on the draft blog post. The links to the pull requests 
> will be replaced with links to the docs once those PRs are reviewed and 
> merged.
>
> Security advisory: Strengthening the password hashes in your database
>
> Summary: If you have MD5 or SHA1 password hashes in your database, here's 
> a way to update them without requiring all your users to login again.
>
> Body:
>
> Are the password hashes in your database strong enough to prevent them 
> from being cracked if your database is compromised?
>
> Django 0.90 stored passwords as unsalted MD5. Django 0.91 added support 
> for salted SHA1 with automatic upgrade of passwords when a user logs in. 
> Django 1.4 added PBKDF2 as the default password hasher.
>
> If you have an old Django project with MD5 or SHA1 (even salted) encoded 
> passwords, be aware that these can be cracked fairly easily with today's 
> hardware. Consider using a `wrapped password hasher <
> https://github.com/django/django/pull/6114>`_ to strengthen the hashes in 
> your database. Django 1.10 will `remove the MD5 and SHA1 hashers <
> https://github.com/django/django/pull/6103>`_ from the default 
> ``PASSWORD_HASHERS`` setting to force projects to acknowledge continued use 
> of a weak hasher.
>
> On Wednesday, February 17, 2016 at 1:24:04 PM UTC-5, Tim Graham wrote:
>>
>> To answer my own question, I did a little experiment and cracked about 
>> 10% of the SHA1 password hashes in the djangoproject.com database in 
>> minutes on my several year old PC.
>>
>> I think that's sufficiently weak to:
>> 1. Make a blog post recommending that projects upgrade using the 
>> instructions in [1] 
>> 2. Remove SHA1PasswordHasher from the default PASSWORD_HASHERS in Django 
>> 1.10 to force projects to explicitly acknowledge use of an insecure hash if 
>> they require it.
>>
>> [1] https://github.com/django/django/pull/6114
>>
>> On Wednesday, February 10, 2016 at 5:16:11 PM UTC-5, Tim Graham wrote:
>>>
>>> Is salted SHA1 sufficiently insecure to remove it from the default 
>>> PASSWORD_HASHERS or should we leave it for now? Any project created before 
>>> pbkdf2 was introduced in Django 1.4 (March 2012) will likely have some SHA1 
>>> hashes unless all their users have logged in since. I've written 
>>> instructions on how to upgrade such passwords without requiring all your 
>>> users to login [1]. If it's warranted, we could make a blog post advising 
>>> this. 
>>>
>>> [1] https://github.com/django/django/pull/6114 
>>> 
>>>
>>> On Monday, February 8, 2016 at 3:12:28 PM UTC-5, Tim Graham wrote:

 Thanks for the feedback everyone. I've created a few action items:

 https://code.djangoproject.com/ticket/26187 - Remove weak password 
 hashers from the default PASSWORD_HASHERS setting
 https://code.djangoproject.com/ticket/26188 - Document how to wrap 
 password hashers
 https://github.com/django/djangoproject.com/issues/632 - Use a wrapped 
 password hasher to upgrade SHA1 passwords

 On Saturday, February 6, 2016 at 3:56:00 AM UTC-5, Curtis Maloney wrote:
>
> I kept meaning to weigh in on this... but all my points have been 
> made. 
>
> It sounds like the middle ground is to: 
>
> 1) remove them from the default list 
> 2) keep them in the codebase 
> 3) make them noisy (raise warnings) 
> 4) provide docs/tools on how to upgrade 
>
> Then we get "secure by default" (1), as well as "encouraging upgrades" 
> (3), whilst also "supporting slow-to-update installs" (4), and 
> "encouraging best practices" (3). 
>
>
> -- 
> C 
>
>
> On 06/02/16 19:51, Aymeric Augustin wrote: 
> > Yes, that would be good from the “security by default” standpoint. 
> This 
> > would also allow us to trim the full list of hashers which is 
> repeated 
> > several times in the docs. 
> > 
> > -- 
> > Aymeric. 
> > 
> >> On 6 févr. 2016, at 00:03, Tim Graham  >> > wrote: 
> >> 
> >> I would guess most users aren't customizing the default list of 
> >> hashers, so I'd rather remove weak hashers from the 
> PASSWORD_HASHERS 
> >> setting and let anyone who needs to use a weak hasher define their 
> own 
> >> setting (at which point a warning probably isn't needed). Does that 
> >> seem okay? 
> >> 
> >> On Friday, February 5, 2016 at 3:20:41 PM UTC-5, Aymeric Augustin 
> wrote: 
> >> 
> >> Adding a c

Unified temporal subtraction support

[charettes]

I recently worked on making substraction of temporal fields return a
`DurationField` on all database backends[1]:

class TemporalModel(models.Model):
from_date = models.DateField()
to_date = models.DateField()

from_time = models.TimeField()
to_time = models.TimeField()

from_datetime = models.DateTimeField()
to_datetime = models.DateTimeField()


TemporalModel.objects.annotate(
date_delta=F('to_date') - F('from_date'),  # Will be a timedelta
time_delta=F('to_time') - F('from_time'),  # Will be a timedelta
datetime_delta=F('to_datetime') - F('from_datetime'), # Will be a 
timedelta
)

Before this change the substraction operator either didn't work (MySQL, 
SQLite)
or returned inconsistent results (`DateField` - `DateField` returned an 
`int`
for the number of days on Oracle and PostgreSQL).

Now that all the tests are passing on all backends I'd like to get feedback 
on
two design decisions I took.

First, should we make substraction of `DateField`s return an integer 
instead of
a `timedelta` just like Oracle and PostgreSQL do by default? I initialy 
chose to
return a `timedelta` (use `DurationField` as `output_field`) because while 
it
made more sense to return an `int` from a SQL point of view I felt like the
former was more appropriate for the level of abstraction the ORM deals 
with. The
use of `timedelta` also introduces a backward incomptiblity issue for users 
of
Oracle and PostgreSQL before the unification effort.

My second concerns is about subtraction of temporals of different types. As
noted on the pull request I can see value in implementing the `DateField` 
and
`DateTimeField` cases but I'm not convinced it's even worth it.

For reference here's the different signatures of the `-` operator of 
PostgreSQL:

| LHS type  | RHS type  | Return type
| - | - | -
| date  | date  | integer
| date  | time  | timestamp
| date  | timestamp | interval
| time  | date  | _undefined_
| time  | time  | interval
| time  | timestamp | _undefined_
| timestamp | date  | interval
| timestamp | time  | timestamp
| timestamp | timestamp | interval

As usual, thanks for your feedback.

Simon

[1] https://github.com/django/django/pull/5997

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c71bc8e9-7a88-4098-b7dc-1147d6a6e22a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Lazy operations refactor regression with abstract models #25858

[charettes]

Hi everyone,

I submited a PR[1] that partially reverts the initial fix and document how 
app
relative lazy relationships behave when defined on abstract models 
subclassed as
concrete models in foreign applications.

Reviews welcome!

Simon

[1] https://github.com/django/django/pull/6178

Le mercredi 10 février 2016 16:29:52 UTC-5, charettes a écrit :
>
> I should have mentioned that this behavior is reproducible since at least
> Django 1.6 and has not been introduced by Django 1.8. I wouldn't be 
> surprised
> if it has always been working before the fix was introduced.
>
> Still, as you mentionned the conditions required to achieve this were 
> really
> convoluted before the lazy operations refactor.
>
> Simon
>
> Le mercredi 10 février 2016 16:11:43 UTC-5, Shai Berger a écrit :
>>
>> On Tuesday 09 February 2016 23:33:50 charettes wrote: 
>> > Hi everyone, 
>> > 
>> > The chosen fix[1] unfortunately introduced a new regression[2]. 
>> > 
>> > It looks like the behavior described in the previous ticket was 
>> possible 
>> > with 
>> > Django 1.8 under certain circumstances[3] where the abstract models 
>> defined 
>> > in a foreign application were derived as concrete models in another 
>> > applications 
>> > before the abstract models relations are resolved (if they are ever 
>> > resolved): 
>> > 
>>
>> The explanation is complex enough, the case where it works edgy enough, 
>> that 
>> I'd be content to call this a bug in 1.8. I'm pretty sure the specifics 
>> of this 
>> resolution are not documented, and my sense from reading the ticket is 
>> that if 
>> you'd try to document the behavior you'll reach the conclusion that it 
>> probably isn't intentional. 
>>
>> My 2 cents, 
>> Shai. 
>>
>> > 
>> > [1] 
>> https://github.com/django/django/commit/bc7d201bdbaeac14a49f51a9ef292d6 
>> > [2] https://code.djangoproject.com/ticket/26186 
>> > [3] https://code.djangoproject.com/ticket/26186#comment:8 
>> > [4] https://code.djangoproject.com/ticket/24215 
>>
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fa69a047-a210-4a7a-a62c-26298eef4005%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: % vs {} string formatting for public APIs

[James Bennett]

The only argument I see for format() over the % operator is that bytes
objects explicitly do not have the format() method and so it'll catch
errors where a bytes object is passed to something expecting a string.

But since we're already Unicode-ifying everything at the boundaries and
have been since before Python 3 existed, I don't think there's much gain
from that, and it's not like %-formatting is going away. So I'd argue that
it's fine to keep things as they are for now, use format() in future
commits if it's cleaner, or just adopt a policy of "if you're in there
making a change and it won't break back compat, feel free to update to
format() while you're at it" for people doing patches, rather than try to
force all usage to convert in one go.

On Mon, Feb 22, 2016 at 10:48 AM, Claude Paroz  wrote:

> Hello,
>
> I don't see much gain with that change, except for specific cases. This
> would also bring a bunch of compatibility issues. I'd rather make the
> change when it does bring something. I understand your consistency
> argument, but we need to balance that with the work generated by the change
> in all existin projects. A -0 from me.
>
> Claude
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/5c9a0cfa-d618-470e-9530-522b0466d6f8%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9Rq8yz095k_qkrb7exy5EbRj%3DsD09cqi6T8%3DNTT6nd4w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: % vs {} string formatting for public APIs

[Claude Paroz]

Hello,

I don't see much gain with that change, except for specific cases. This 
would also bring a bunch of compatibility issues. I'd rather make the 
change when it does bring something. I understand your consistency 
argument, but we need to balance that with the work generated by the change 
in all existin projects. A -0 from me.

Claude

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5c9a0cfa-d618-470e-9530-522b0466d6f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding SASL authentication support to PyLibMCCache

[Claude Paroz]

Le lundi 22 février 2016 13:00:31 UTC+1, Ed Morley a écrit :
>
> (...)
>
> I'm happy to put together a PR to make the impact/complexity easier to 
> judge, if that helps?
>
>
Yes, it always help to see the code. 
 

> Before I do that I would just need to know whether the `username`, 
> `password` and `binary` fields should be added to the top level 
> `CACHES['foo']` dict, or nested inside `OPTIONS` within that? Examples:
> https://emorley.pastebin.mozilla.org/8858134
>

I would say that if username and password are not mandatory, put them in 
options. But no strong opinion here.

Claude

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/774dd4dc-b45e-4d2d-b25a-d12d081ca53f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: % vs {} string formatting for public APIs

[Tim Graham]

As Claude noted in the ticket for the success_url change:

"I think that using the old percent-based interpolation method in 
get_success_url was not very wise, considering that % is a common escape 
marker in URLs. I'd suggest using the new format interpolation method to 
elude conflicts with escaping percent characters in URLs."
https://code.djangoproject.com/ticket/24133

I guess I don't see much downside to making the change as you suggested 
except that it could be quite tedious for large projects to adapt.

On Thursday, February 18, 2016 at 12:30:35 AM UTC-5, Jon Dufresne wrote:
>
> Hi, 
>
> I noticed that some Django public APIs use the % old-style string 
> formatting while others use the {} new-style formatting. 
>
> For example: 
>
> {} style 
>
> * success_url [0] (Converted to {} in 1.8) 
> * format_html [1] 
>
> % style 
>
> * ValidationError [2] 
> * related_name [3] 
>
>
> Is this difference intentional? 
>
> As success_url recently moved to {}, I'm guessing {} is Django's 
> preferred style? 
>
> If this different is not intentional, I would like to propose a change 
> to ValidationError to use the {} style formatting. This change would 
> go through the same deprecation path as used by success_url. Thoughts? 
>
> I think this would create a greater API consistency throughout the 
> framework. I think using a single, consistent string formatting API 
> follows the design philosophy "principle of least surprise". 
>
> Ultimately, I don't care what format is preferred, but I think one 
> should be used consistently. 
>
> I have created a proof of concept as to what this would mean as a 
> change. The change still requires new tests and docs; so it still WIP. 
>
>
> https://github.com/django/django/compare/master...jdufresne:remove-percent-placeholder
>  
>
> If there is support for this change, I would like to follow through a 
> ticket and finished PR. 
>
> Cheers, 
> Jon 
>
>
> [0] 
> https://docs.djangoproject.com/en/1.9/ref/class-based-views/mixins-editing/#django.views.generic.edit.ModelFormMixin.success_url
>  
> [1] 
> https://docs.djangoproject.com/en/1.9/ref/utils/#django.utils.html.format_html
>  
> [2] 
> https://docs.djangoproject.com/en/1.9/ref/forms/validation/#raising-validationerror
>  
> [3] 
> https://docs.djangoproject.com/en/1.9/topics/db/models/#be-careful-with-related-name
>  
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6147f047-403c-4036-a0f4-3e550b01c452%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Not able to install Django in Windows10

[gilberto dos santos alves]

Hi. Please verify:

1 - what is your version especify name (home, professional, etc) 32 or
64bits, locale / language, python version

2 - look at your environment var system %PATH% (not user path) (to see open
cmd and echo %PATH%

3 - if your %PATH% do not have python/scripts folder declared or firewall
active block python pip executions.



2016-02-22 3:09 GMT-03:00 Nasif Noorudeen :

> I am not able to install Django 1.9.2(any version of Django ) in Windows
> 10. I am using following command to install Django
>
> pip install Django==1.9.2
>
> it is working fine in Windows 8 and Windows 7. It seems like this is is the 
> issue with pip tool
>
> If i simply type pip.exe also nothing is happening in console.
>
> If anyone facing same issue in Windows 10. Please help to solve this
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/aa1bc911-cf2d-4e41-8872-4382c0133f21%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
gilberto dos santos alves
+55(11)9-8646-5049
sao paulo - sp - brasil

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAP9G-N%2B4wt%2BC%2BLvXz1Re4A9n2En32Nac-a_b5yQc0EjkDpeS1w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding SASL authentication support to PyLibMCCache

[Ed Morley]

Hi Tim,

Thank you for your reply. 

Yeah I spotted that discussion (it's [6] in the OP). Back then Heroku (and 
other PaaS providers) were less common (and I'm not sure how many of those 
users frequent this list).

Given that django-pylibmc has 8000 downloads a month on PyPI (and this is 
bearing in mind that Heroku re-uses the virtualenv, so Heroku deployments 
won't be counted in that figure aside from updates) I think there is a case 
for including it in the default backend - given it would only be a 5-10 
line addition. Even for people who won't be using auth, the new binary mode 
is faster, so could be useful regardless.

I'm happy to put together a PR to make the impact/complexity easier to 
judge, if that helps?

Before I do that I would just need to know whether the `username`, 
`password` and `binary` fields should be added to the top level 
`CACHES['foo']` dict, or nested inside `OPTIONS` within that? Examples:
https://emorley.pastebin.mozilla.org/8858134

Many thanks,

Ed

On Monday, 1 February 2016 18:47:17 UTC, Tim Graham wrote:
>
> I found an old discussion about it, but it didn't attract much interest at 
> the time: 
> https://groups.google.com/d/topic/django-developers/pISp20wuu0E/discussion
>
> On Saturday, January 30, 2016 at 7:21:49 PM UTC-5, Ed Morley wrote:
>>
>> Hi
>>
>> For apps running on Heroku, two of the main memcached options are 
>> MemCachier and Memcached Cloud [1]. Both of these control access via SASL 
>> authentication, which isn't supported by Django's current pylibmc backend 
>> [2], even though pylibmc supports it [3]. As such, currently the 
>> django-pylibmc backend has to be used instead [4].
>>
>> I'd like to add SASL auth support to the Django pylibmc backend to make 
>> this unnecessary, which is just a case of passing the relevant parameters 
>> through to the pylibmc client during its instantiation [5]. A previous 
>> newsgroup discussion about this is at [6].
>>
>> SASL auth requires binary mode, so I'll also need to add support for that 
>> - for which there is already a Django ticket filed [7].
>>
>> I have a couple of questions:
>> a) Will a PR to add SASL authentication support be accepted?
>> b) If yes to (a), should the `username`, `password` and `binary` fields 
>> be added to the top level `CACHES['foo']` dict, or nested inside `OPTIONS` 
>> within that? I'm presuming within OPTIONS? Examples: [8].
>>
>> Many thanks,
>>
>> Ed
>>
>> [1] https://elements.heroku.com/addons#caching
>> [2] 
>> https://github.com/django/django/blob/1.9.1/django/core/cache/backends/memcached.py#L181
>> [3] 
>> https://github.com/lericson/pylibmc/blob/1.5.0/src/pylibmc/client.py#L125
>> [4] https://github.com/django-pylibmc/django-pylibmc
>> [5] eg: 
>> https://github.com/django-pylibmc/django-pylibmc/blob/v0.6.1/django_pylibmc/memcached.py#L85-L91
>> [6] 
>> https://groups.google.com/forum/#!searchin/django-developers/pylibmc/django-developers/pISp20wuu0E/tamJ1h8zCzsJ
>> [7] https://code.djangoproject.com/ticket/15815
>> [8] https://emorley.pastebin.mozilla.org/8858134
>>
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8e19c698-5a3c-4aee-88fe-267cfb515a9a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Not able to install Django in Windows10

[Dmitry Gladkov]

Hi Nasif,

My colleague had the same problem couple of days ago with running pip on
Windows and in his case the problem was that antivirus software (Avast in
his case) blocked execution of pip process.

Having said that, this is clearly a pip related problem, so please move
further discussion to pip mailing list

--
Best wishes,
Dmitry Gladkov, mailto:dmitry.glad...@gmail.com

+380 91 303-37-46

On 22 February 2016 at 08:09, Nasif Noorudeen  wrote:

> I am not able to install Django 1.9.2(any version of Django ) in Windows
> 10. I am using following command to install Django
>
> pip install Django==1.9.2
>
> it is working fine in Windows 8 and Windows 7. It seems like this is is the 
> issue with pip tool
>
> If i simply type pip.exe also nothing is happening in console.
>
> If anyone facing same issue in Windows 10. Please help to solve this
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/aa1bc911-cf2d-4e41-8872-4382c0133f21%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CA%2BkbqrVFpzA60fUHBkH6ws0r75EadaTwiChrHDQ9YvmsxWH51A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Composite Primary Keys

[Michal Petrucha]

On Tue, Feb 16, 2016 at 05:38:12PM -0800, Cristiano Coelho wrote:
> Hello there,
> 
> What's the status for this? This 
> (https://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys) is 3 years 
> old (last edit) and the links on it are even older. Googling around only 
> gave me some very old projects so it wasn't good neither.

Hi Cristiano,

I personally have spent in total perhaps about a year (or even more)
working on this (which includes two Summer of Code programs).
Unfortunately, my work was spread over more than three years, which
means a significant chunk of effort went into keeping up with changes
in Django and, ultimately, that's the part at which I failed. Twice.
(With a patch of this magnitude, all you need is to fall behind by
three weeks, and it gets very difficult and/or time-consuming to merge
new changes into it.)

The latest effort was launched by Thomas Stephenson, and resulted in
the following DEP:
https://github.com/django/deps/blob/master/draft/0191-composite-fields.rst,

There was even a pull request, but eventually, Thomas withdrew his
patch. You can find the corresponding thread on this mailing list
here:
https://groups.google.com/d/msgid/django-developers/ed326cce-6784-429b-869b-f6f66d3c77fd%40googlegroups.com

I wasn't around at that particular time, and I haven't yet found the
time to carefully read that thread and let it sink in, but I can give
a summary of my observations from 2013, when I last worked on this.

If you're interested, you can take a look at the wall of text I wrote
as my GSoC proposal in 2013: https://gist.github.com/konk/5408673.
You might also want to search this mailing list for previous threads
about this topic.


I seem to recall that just the most basic functionality of
CompositeField was the easy part. At that time (before migrations
landed), it meant mostly just making some parts of Django play nicer
with virtual fields (which was an almost entirely unexplored concept
in Django back then), some hackery for query lookups (since we didn't
have the nice API for custom lookups and transforms), and a fancy
class to represent composite values in model instances. Whipping up
something like this takes a few days, at most weeks, of focused work,
and you can have something sort of usable, with many sharp edges that
you have to keep in mind.

Things start to get ugly when you try to make CompositeField play nice
with the rest of the ORM, and the most obvious troublemaker is
ForeignKey. Composite ForeignKey is something that requires a big
refactor of the way related fields work, but even with a simple
ForeignKey to a unique column on a model with a composite primary key,
you'd start stumbling on errors with Python-level delete cascades,
prefetching and such -- those require an overhaul of how __in lookups
are handled. Then there are things like generic foreign keys, database
migrations, introspection, and potentially other features that would
need to be taken into account. Most of them could be postponed to a
later time, but some of them would most likely have to be part of the
initial patch.

Anyway, with the recent _meta refactor, reimplementing ForeignKey as a
virtual field should hopefully be easier now, although no one will
know for sure unless someone actually steps up and tries to do it. I
certainly hope that I'll be able to tackle this once again, but I
cannot make any promises.


Cheers,

Michal

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20160222102153.GH880%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Not able to install Django in Windows10

[Nasif Noorudeen]

I am not able to install Django 1.9.2(any version of Django ) in Windows 
10. I am using following command to install Django

pip install Django==1.9.2

it is working fine in Windows 8 and Windows 7. It seems like this is is the 
issue with pip tool

If i simply type pip.exe also nothing is happening in console.

If anyone facing same issue in Windows 10. Please help to solve this

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/aa1bc911-cf2d-4e41-8872-4382c0133f21%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.