Do I need to extend User in Django with REST framework?

[周鸿宇]

I used to define my User model that run with initally (Tested very good), 
then I want to import REST framework to deal with urls and views, but it 
looks like friendly with Django's User model but not me... So I am think 
that is it a good idea to add it (I remove the auth App at frist), and then 
extend it as my own User model?

By the way, how to help to translate the document? I want to join you.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/938a4ef9-a27d-4f85-ba55-3435ca61d93cn%40googlegroups.com.

Re: Making max_length argument optional

[Bryce Groff]

My 2 cents as a non core developer.

On Wednesday, August 12, 2020, t...@carrick.eu  wrote:
>
>
> Give CharField a default max_length that is consistent across all vendors.
> It doesn't really matter what the number is other than that it should be
> large enough to be useful but small enough to work everywhere. I think 100
> or 255 are both fine options.
>

I think this could be a good idea, but I think it breaks the ethos of
explicit is better than implicit. I can see where a user/developer would
get errors (validation or db constraints) that would be very confusing as
you would not know where the 100 or 255 value comes from.


> If you set max_length=None explicitly, on Postgres this will use an
> unlimited varchar, on everything else will raise an exception on migrate.
>

This would be very nice to have personally. I think it would need a
security warning in the docs saying that this could be used as a ddos
vector though. And as a potential security issue where is djangos
responsibility to provide a potential footgun?


Bryce

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEKFToBJ9RJb6EbDh_ydypkgXCL1WZO4k6KENiabOjXR1EcewQ%40mail.gmail.com.

Re: Do I need to extend User in Django with REST framework?

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/3.0/faq/help/ . This will help you find
people who are willing to support you, and to ask your question in a way
that makes it easy for them to answer.

Thanks for your understanding and all the best,

Adam

On Sun, 16 Aug 2020 at 13:51, 周鸿宇  wrote:

> I used to define my User model that run with initally (Tested very good),
> then I want to import REST framework to deal with urls and views, but it
> looks like friendly with Django's User model but not me... So I am think
> that is it a good idea to add it (I remove the auth App at frist), and then
> extend it as my own User model?
>
> By the way, how to help to translate the document? I want to join you.
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/938a4ef9-a27d-4f85-ba55-3435ca61d93cn%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2Z%2BiNYF%3DOxxr67NxoNTQrqYNeWANm7PrkSACegx5nH8A%40mail.gmail.com.

Re: Making max_length argument optional

[Tom Forbes]

I’m not a fan of implicit max_lengths. Is having to add a keyword argument to a 
model field really that much of a burden? And we also would likely never be 
able to change the default without headaches.

> On 12 Aug 2020, at 13:19, t...@carrick.eu  wrote:
> 
> I'd like to revive this discussion and try to come to a consensus as it's 
> something I find myself wishing for (for Postgres in particular).
> 
> My suggestion, after reading through everything:
> 
> Give CharField a default max_length that is consistent across all vendors. It 
> doesn't really matter what the number is other than that it should be large 
> enough to be useful but small enough to work everywhere. I think 100 or 255 
> are both fine options.
> 
> If you set max_length=None explicitly, on Postgres this will use an unlimited 
> varchar, on everything else will raise an exception on migrate.
> 
> Any thoughts?
> 
> Cheers,
> Tom
> 
> On Saturday, March 5, 2016 at 2:13:14 PM UTC+1 Shai Berger wrote:
> On Saturday 05 March 2016 02:24:17 Loïc Bistuer wrote: 
> > I’m not too keen on a contrib.pg  field. CharField is 
> > the base class of many 
> > fields, a __init__ kwarg approach such as max_length=None allows us to 
> > reach those as well. 
> > 
> 
> That's a good point; Can we enable max_length=None in a mixin? 
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/dfaaa9d3-dff3-46a3-899f-dd7f4eddfe87n%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/468B12C0-2864-4221-9985-044F340E56E1%40tomforb.es.

Re: Making max_length argument optional

[Carlton Gibson]

Reading the history, I see an awful lot of -1s to the idea of a default.

I see “use a TextField” and “use a subclass” a few times, which were my
immediate thoughts just on the recent emails.

On Sun, 16 Aug 2020 at 18:47, Tom Forbes  wrote:

> I’m not a fan of implicit max_lengths. Is having to add a keyword argument
> to a model field really that much of a burden? And we also would likely
> never be able to change the default without headaches.
>
> On 12 Aug 2020, at 13:19, t...@carrick.eu  wrote:
>
> I'd like to revive this discussion and try to come to a consensus as it's
> something I find myself wishing for (for Postgres in particular).
>
> My suggestion, after reading through everything:
>
> Give CharField a default max_length that is consistent across all vendors.
> It doesn't really matter what the number is other than that it should be
> large enough to be useful but small enough to work everywhere. I think 100
> or 255 are both fine options.
>
> If you set max_length=None explicitly, on Postgres this will use an
> unlimited varchar, on everything else will raise an exception on migrate.
>
> Any thoughts?
>
> Cheers,
> Tom
>
> On Saturday, March 5, 2016 at 2:13:14 PM UTC+1 Shai Berger wrote:
>
>> On Saturday 05 March 2016 02:24:17 Loïc Bistuer wrote:
>>
>>
>> > I’m not too keen on a contrib.pg field. CharField is the base class of
>> many
>>
>>
>> > fields, a __init__ kwarg approach such as max_length=None allows us to
>>
>>
>> > reach those as well.
>>
>>
>> >
>>
>>
>>
>>
>>
>> That's a good point; Can we enable max_length=None in a mixin?
>>
>>
>>
>
>
>
>
> --
>
>
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/dfaaa9d3-dff3-46a3-899f-dd7f4eddfe87n%40googlegroups.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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/468B12C0-2864-4221-9985-044F340E56E1%40tomforb.es
> 
> .
>
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJwKpyScwiRJWWebwjQZ4qoQz6_zuWZP9Q_RAs8bxzV0eRMoqQ%40mail.gmail.com.