Add image and phone_number fields to Django User auth model

[Muhammad Shehzad]

Hey Developers! Some fields should be inside models.User e.g. image, 
phone_number. Some developers don't want to extend the auth model. Yes i 
know there are some ways to extends the auth model. But i think these 
fields should come with models.User

-- 
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/da95c74b-413c-41f0-85b5-9bef2320eecfn%40googlegroups.com.

Feature request: Template tag like stateless component in JSX React

[Aztec Rabbit]

Hi,

I think template tag like in JSX is very useful, for example:

> card.html


  {{ title }}
  {{ component.children }}


> index.html

{% component './card.html' with title='Foo' %}
  Bar
{% endcomponent %}

-- 
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/ff75ddef-2267-44f5-89f7-9b8ebf1460efn%40googlegroups.com.

Re: Feature request: Template tag like stateless component in JSX React

[Jure Erznožnik]

We have just created a tag like that in our dynamicforms library. It's 
called "extendtemplateblock". Feel free to use or copy, but it doesn't 
look like it's going to be accepted in Django itself.


We tried to keep API similar to the "include" tag, so it should be easy 
to use.


You can choose to only pull one block from your extended template 
("block" parameter) or define any of the blocks in it using "block" 
nested blocks.


LP,
Jure

On 28. 01. 21 07:33, Aztec Rabbit wrote:

Hi,

I think template tag like in JSX is very useful, for example:

> card.html


  {{ title }}
  {{ component.children }}


> index.html

{% component './card.html' with title='Foo' %}
  Bar
{% endcomponent %}
--
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/ff75ddef-2267-44f5-89f7-9b8ebf1460efn%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/c5dbb94b-8b3a-ef27-92b6-c90018f2bc85%40gmail.com.

Re: Add image and phone_number fields to Django User auth model

[Jacob Rief]

No they should not!

Django provides an easy way to extend (or replace) the built-in User model. 
There are far too many fields people might want to add and it would be a 
complete mess, if we would fulfill all of these requests.
Please refer to the docs 
at 
https://docs.djangoproject.com/en/3.1/topics/auth/customizing/#auth-custom-user

-- 
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/ade56f54-17da-4647-aab3-22909a113763n%40googlegroups.com.

Re: Add image and phone_number fields to Django User auth model

[Ken Whitesell]

I can see where you might think that, but I actually believe it should 
go in the other direction - that the User model should be the absolute 
_minimum_ of an entity.


1. The User model is retrieved with every authenticated request. The 
more fields in the model, the more data is being handled unnecessarily. 
(Do you really need the User phone number with every request?)


2. If you go in that direction, there's no way you're going to reach a 
consensus as to what fields should be included, or to make a valid 
argument against field "X" once field "Y" has been added - ending up 
with an extremely over-bloated object.


3. It's too easy to extend or replace the user model. The process is 
well-documented. Saying "some developers don't want to" do something 
doesn't constitute a reason.


(I'm an extremist in the other direction. I believe that the User model 
should only consist of the PK, and an "active" flag. All other 
information can be stored in ancillary tables - but I acknowledge that 
that's very much a minority position as well.)



On 1/28/2021 8:25 AM, Muhammad Shehzad wrote:
Hey Developers! Some fields should be inside models.User e.g. image, 
phone_number. Some developers don't want to extend the auth model. Yes 
i know there are some ways to extends the auth model. But i think 
these fields should come with models.User

--
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/da95c74b-413c-41f0-85b5-9bef2320eecfn%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/d0f5e304-f1f1-19d0-4300-37f3961b270b%40comcast.net.

Re: Feature request: Template tag like stateless component in JSX React

[Aztec Rabbit]

Is there a link to the documentation or source code to the library you 
created? And can i know why it is not accepted?

On Thursday, January 28, 2021 at 9:34:03 PM UTC+7 jure.er...@gmail.com 
wrote:

> We have just created a tag like that in our dynamicforms library. It's 
> called "extendtemplateblock". Feel free to use or copy, but it doesn't look 
> like it's going to be accepted in Django itself.
>
> We tried to keep API similar to the "include" tag, so it should be easy to 
> use.
>
> You can choose to only pull one block from your extended template ("block" 
> parameter) or define any of the blocks in it using "block" nested blocks. 
>
> LP,
> Jure
> On 28. 01. 21 07:33, Aztec Rabbit wrote:
>
> Hi, 
>
> I think template tag like in JSX is very useful, for example:
>
> > card.html
>
> 
>   {{ title }}
>   {{ component.children }}
> 
>
> > index.html
>
> {% component './card.html' with title='Foo' %}
>   Bar
> {% endcomponent %}
>
> -- 
> 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-develop...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/ff75ddef-2267-44f5-89f7-9b8ebf1460efn%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/0cb2a1f6-9070-4875-90e2-eb6da241ea82n%40googlegroups.com.

Re: Feature request: Template tag like stateless component in JSX React

[Curtis Maloney]

I did something like this in django-sniplates 

https://sniplates.readthedocs.io/en/latest/tags.html#the-nested-widget-tag

--
C

On Thu, 28 Jan 2021, at 17:33, Aztec Rabbit wrote:
> Hi,
> 
> I think template tag like in JSX is very useful, for example:
> 
> > card.html
> 
> 
>   {{ title }}
>   {{ component.children }}
> 
> 
> > index.html
> 
> {% component './card.html' with title='Foo' %}
>   Bar
> {% endcomponent %}
> 

> -- 
> 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/ff75ddef-2267-44f5-89f7-9b8ebf1460efn%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/4a8767e0-63a9-4b34-81c7-aea75a67f653%40www.fastmail.com.

Re: Add image and phone_number fields to Django User auth model

[Curtis Maloney]

I second this; I would have moved to having auth.User be abstract, and force 
projects to create their own _always_, except (a) it breaks a lot of history, 
and (b) it breaks the "ready to go out of the box" nature.

It's a small cost at the start of your project, that avoids problems for a 
sizable portion of all projects which end up customising User.

It also makes it more obvious that you _can_ customise user; that it's just 
like any other model.

--
C


On Fri, 29 Jan 2021, at 02:00, Ken Whitesell wrote:
> I can see where you might think that, but I actually believe it should go in 
> the other direction - that the User model should be the absolute _minimum_ of 
> an entity.
> 
> 1. The User model is retrieved with every authenticated request. The more 
> fields in the model, the more data is being handled unnecessarily. (Do you 
> really need the User phone number with every request?)
> 
> 2. If you go in that direction, there's no way you're going to reach a 
> consensus as to what fields should be included, or to make a valid argument 
> against field "X" once field "Y" has been added - ending up with an extremely 
> over-bloated object.
> 
> 3. It's too easy to extend or replace the user model. The process is 
> well-documented. Saying "some developers don't want to" do something doesn't 
> constitute a reason.
> 
> (I'm an extremist in the other direction. I believe that the User model 
> should only consist of the PK, and an "active" flag. All other information 
> can be stored in ancillary tables - but I acknowledge that that's very much a 
> minority position as well.)
> 
> 
> On 1/28/2021 8:25 AM, Muhammad Shehzad wrote:
>> Hey Developers! Some fields should be inside *models.**User* e.g. image, 
>> phone_number. Some developers don't want to extend the auth model. Yes i 
>> know there are some ways to extends the auth model. But i think these fields 
>> should come with *models.**User*
>> -- 
>> 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/da95c74b-413c-41f0-85b5-9bef2320eecfn%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/d0f5e304-f1f1-19d0-4300-37f3961b270b%40comcast.net
>  
> .

-- 
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/a709adc2-1656-4e6c-b8af-9f01805552fa%40www.fastmail.com.

Increase default integer keys to 64 bits

[Christophe Pettus]

tl;dr: Introduce new field types to handle auto-incremented ID fields, change 
the PostgreSQL backend to use the preferred syntax

--

One of the most common issues my company runs into on Django sites is that 
models.AutoField defaults to a 32-bit integer (int32).  2^31-1 possible entries 
is just not that many anymore, and by the time the developers realize this and 
need to move to a 64 bit integer key, it's too late to do so conveniently, 
because expanding the field is very painful (in PostgreSQL, at least).

While models.AutoBigField exists, it's barely mentioned in examples, and is 
often overlooked.

Changing AutoField to 64 bits would result in all kinds of breakage; at best, a 
lot of very unplanned and expensive migrations.

My proposal is:

1. Create two new field types to represent auto-incrementing primary keys.  I'd 
suggest IdentityField and SmallIdentityField for int64 and int32, respectively.

2. Change all examples to use SerialField instead of AutoField.

3. As a side note, switch the PostgreSQL backend to use the standard "GENERATED 
BY DEFAULT AS IDENTITY" syntax.  This became available in PostgreSQL version 
10, but the previous version (9.6) reaches EOL in November 2021.

4. At some point in the future, deprecate AutoField and AutoBigField.

This would result in new projects getting 64 bit primary keys by default.  I 
think that's a positive.  For small tables, the size difference hardly matters; 
for big tables, we have saved a major foot-gun of either integer exhaustion or 
a very expensive data migration problem.

--

Comments?

--
-- Christophe Pettus
   x...@thebuild.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/F4A50AB6-8CC1-4B6E-BD1B-B865F53A645A%40thebuild.com.

Re: Increase default integer keys to 64 bits

[Curtis Maloney]

I recall a discussion some time about about adding a setting to control which 
field to use for the default PK... seems there's some overlap here.

--
C


On Fri, 29 Jan 2021, at 12:42, Christophe Pettus wrote:
> tl;dr: Introduce new field types to handle auto-incremented ID fields, change 
> the PostgreSQL backend to use the preferred syntax
> 
> --
> 
> One of the most common issues my company runs into on Django sites is that 
> models.AutoField defaults to a 32-bit integer (int32).  2^31-1 possible 
> entries is just not that many anymore, and by the time the developers realize 
> this and need to move to a 64 bit integer key, it's too late to do so 
> conveniently, because expanding the field is very painful (in PostgreSQL, at 
> least).
> 
> While models.AutoBigField exists, it's barely mentioned in examples, and is 
> often overlooked.
> 
> Changing AutoField to 64 bits would result in all kinds of breakage; at best, 
> a lot of very unplanned and expensive migrations.
> 
> My proposal is:
> 
> 1. Create two new field types to represent auto-incrementing primary keys.  
> I'd suggest IdentityField and SmallIdentityField for int64 and int32, 
> respectively.
> 
> 2. Change all examples to use SerialField instead of AutoField.
> 
> 3. As a side note, switch the PostgreSQL backend to use the standard 
> "GENERATED BY DEFAULT AS IDENTITY" syntax.  This became available in 
> PostgreSQL version 10, but the previous version (9.6) reaches EOL in November 
> 2021.
> 
> 4. At some point in the future, deprecate AutoField and AutoBigField.
> 
> This would result in new projects getting 64 bit primary keys by default.  I 
> think that's a positive.  For small tables, the size difference hardly 
> matters; for big tables, we have saved a major foot-gun of either integer 
> exhaustion or a very expensive data migration problem.
> 
> --
> 
> Comments?
> 
> --
> -- Christophe Pettus
>x...@thebuild.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/F4A50AB6-8CC1-4B6E-BD1B-B865F53A645A%40thebuild.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/50ec245f-21a4-4ab9-ac51-55be2c969310%40www.fastmail.com.

Re: Increase default integer keys to 64 bits

[Tom Forbes]

Better than that: 3.2 is the first step to changing the default. See 
“customising the type of primary keys” in the release notes 
(https://docs.djangoproject.com/en/dev/releases/3.2/).

“GENERATED BY DEFAULT AS IDENTITY” would be a nice improvement though.

Tom

> On 29 Jan 2021, at 01:58, Curtis Maloney  wrote:
> 
> 
> I recall a discussion some time about about adding a setting to control which 
> field to use for the default PK... seems there's some overlap here.
> 
> --
> C
> 
> 
>> On Fri, 29 Jan 2021, at 12:42, Christophe Pettus wrote:
>> tl;dr: Introduce new field types to handle auto-incremented ID fields, 
>> change the PostgreSQL backend to use the preferred syntax
>> 
>> --
>> 
>> One of the most common issues my company runs into on Django sites is that 
>> models.AutoField defaults to a 32-bit integer (int32).  2^31-1 possible 
>> entries is just not that many anymore, and by the time the developers 
>> realize this and need to move to a 64 bit integer key, it's too late to do 
>> so conveniently, because expanding the field is very painful (in PostgreSQL, 
>> at least).
>> 
>> While models.AutoBigField exists, it's barely mentioned in examples, and is 
>> often overlooked.
>> 
>> Changing AutoField to 64 bits would result in all kinds of breakage; at 
>> best, a lot of very unplanned and expensive migrations.
>> 
>> My proposal is:
>> 
>> 1. Create two new field types to represent auto-incrementing primary keys.  
>> I'd suggest IdentityField and SmallIdentityField for int64 and int32, 
>> respectively.
>> 
>> 2. Change all examples to use SerialField instead of AutoField.
>> 
>> 3. As a side note, switch the PostgreSQL backend to use the standard 
>> "GENERATED BY DEFAULT AS IDENTITY" syntax.  This became available in 
>> PostgreSQL version 10, but the previous version (9.6) reaches EOL in 
>> November 2021.
>> 
>> 4. At some point in the future, deprecate AutoField and AutoBigField.
>> 
>> This would result in new projects getting 64 bit primary keys by default.  I 
>> think that's a positive.  For small tables, the size difference hardly 
>> matters; for big tables, we have saved a major foot-gun of either integer 
>> exhaustion or a very expensive data migration problem.
>> 
>> --
>> 
>> Comments?
>> 
>> --
>> -- Christophe Pettus
>>x...@thebuild.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/F4A50AB6-8CC1-4B6E-BD1B-B865F53A645A%40thebuild.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/50ec245f-21a4-4ab9-ac51-55be2c969310%40www.fastmail.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/DCEFF85C-0C69-4C63-8E50-B7A4D36ADA1E%40tomforb.es.

Re: Feature request: Template tag like stateless component in JSX React

[Jure Erznožnik]

Source is here 
(https://github.com/velis74/DynamicForms/blob/master/dynamicforms/templatetags/dynamicforms.py
- see at end of file), documentation will follow shortly as we near
1.0 release (right now it's pretty pathetic, but it is there at
readthedocs), but there are examples & unit tests included showing
most of the functionality.

As far as I understood the feature wasn't perceived as something that
would improve Django as a whole. There is that thing we need to be
wary of - feature creep. Generally added features are preferred to be
provided as third party libraries. Easier to maintain, easier to find
that exact match you're looking for. Just look: Curtis also pointed
you to his own version, a bit different that ours, but maybe it would
suit you more?

LP,
Jure

On Thu, Jan 28, 2021 at 6:52 PM Aztec Rabbit  wrote:
>
> Is there a link to the documentation or source code to the library you 
> created? And can i know why it is not accepted?
>
> On Thursday, January 28, 2021 at 9:34:03 PM UTC+7 jure.er...@gmail.com wrote:
>>
>> We have just created a tag like that in our dynamicforms library. It's 
>> called "extendtemplateblock". Feel free to use or copy, but it doesn't look 
>> like it's going to be accepted in Django itself.
>>
>> We tried to keep API similar to the "include" tag, so it should be easy to 
>> use.
>>
>> You can choose to only pull one block from your extended template ("block" 
>> parameter) or define any of the blocks in it using "block" nested blocks.
>>
>> LP,
>> Jure
>>
>> On 28. 01. 21 07:33, Aztec Rabbit wrote:
>>
>> Hi,
>>
>> I think template tag like in JSX is very useful, for example:
>>
>> > card.html
>>
>> 
>>   {{ title }}
>>   {{ component.children }}
>> 
>>
>> > index.html
>>
>> {% component './card.html' with title='Foo' %}
>>   Bar
>> {% endcomponent %}
>>
>> --
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/ff75ddef-2267-44f5-89f7-9b8ebf1460efn%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/0cb2a1f6-9070-4875-90e2-eb6da241ea82n%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/CAJ%3D9zieGEbEEZkRCNU_hbS7ya%3DBiVgt3CZ-HV12KBg2OMR8T1Q%40mail.gmail.com.