ver, I do think it has some merits. An obvious benefit to the
> consistency is when you are using another framework with Django which makes
> certain assumptions about the way you identify objects. Some front end
> frameworks prefer guids to integers, as would some security protocols.
>
d
> assumes integers.
>
> However, I do think it has some merits. An obvious benefit to the
> consistency is when you are using another framework with Django which makes
> certain assumptions about the way you identify objects. Some front end
> frameworks prefer guids to integer
I agree with you in recommending against using `.filter(pk=1)` in testing.
What do you think of the idea though. Do you think it would be worth
looking into adding a flag for new projects or not worth the time/effort to
add it.
On Wednesday, August 31, 2016 at 10:11:55 PM UTC-7, Shai Berger wro
or this. Permissions and Groups are
> unlikely to need uuids, and building such a system to swap out the actual
> type for a new one seems like massive overkill just to keep things
> consistent.
>
> I'd be -0 on such a feature.
>
> On Wednesday, 31 August 2016 06:43:02
*Blog:* http://aresou.net | *Github:* https://github.com/aresowj | *Stack
> Overflow:* http://stackoverflow.com/users/5183727/ares-ou
>
> Ares Ou
>
> On Tue, Aug 30, 2016 at 11:43 AM, Tim Graham > wrote:
>
>> Sounds quite complicated. In particular, how could we reason
st 30, 2016 at 11:43:17 AM UTC-7, Tim Graham wrote:
>
> Sounds quite complicated. In particular, how could we reasonably test that
> contrib apps work with arbitrary PKs?
>
> On Tuesday, August 30, 2016 at 2:32:18 PM UTC-4, Emett Speer wrote:
>>
>> Hello Everyone,
&
Hello Everyone,
I would like to propose the exploration of adding a default PK setting do
Django. This could be a flag at project creation time or a setting to be
set before the first migration takes place.
This would allow the developer to set the default PK in Django to something
like UUID.
