Re: Make `raw_id_fields` the default functionality in the admin

[Aymeric Augustin]

Hello,

The default  widget is fine for configuration tables with no more than 
a few dozen values.

In my experience, I rarely encountered use cases for editing foreign keys to 
very large tables in the admin.

Readonly or autocomplete are good choices.

Best regards,

-- 
Aymeric.



> On 17 Oct 2018, at 17:59, Yo-Yo Ma  wrote:
> 
> I have yet to ever come across a situation where the default  field 
> is more useful than the raw ID field, pertaining foreign key fields in the 
> admin.
> 
> I have, however, personally witnessed a major publishing company bring their 
> production app servers to a halt (out of memory) due to Django attempting to 
> generate 2.5 million  tags for some dozen admins that 
> were all refreshing an admin changeview, wondering why it was taking so long 
> to load.
> 
> Another thing worth noting is that when the  is most useful (when 
> there are very few records to select) also happens to be when the raw ID 
> field is most easily used (since the selection changelist only contains the 
> same very few records). IOW, the raw ID field's usefulness is universal, 
> working well with just a few records, and also working well (due to search / 
> sort) when there are many records.
> 
> Nary a transition would be required, since the `raw_id_fields` could simply 
> be ignored.
> 
> A new `select_fields = []` could be added for those who wish to easily  use 
> the old functionality.
> 
> Is there any reason why this couldn't or shouldn't be done?
> 
> 
> -- 
> 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/76e35c9d-b62f-498f-a382-6f12f74ebd98%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/BF6BF10C-BFCE-47FE-A492-EF5B671E1039%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a database-agnostic JSONField into Django

[Raphael Michel]

Hi,

On Saturday, October 20, 2018 at 10:48:04 PM UTC+2, Adam Johnson wrote:
>
> The main thing is that MySQL added a binary JSON type, whilst MariaDB just 
> made the JSON type an alias for TEXT (plus the corollaries that implies): 
> https://mariadb.com/kb/en/library/json-data-type/
>

Yes, this is the main difference, as MySQL requires CAST(x AS JSON) calls 
in many places while MariaDB does not support CAST(x AS JSON). I also noted 
a number of oddities with regards to case-(in)sensitivity when comparing 
values extracted from JSON, but I didn't research this deeper.

Best
Raphael

-- 
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/3d2e6bf8-aa2a-4ece-80bc-5867f8105e04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.