Re: bulk_create for multi table inheritance support
I'm interested in this as well. Two points to make. One, why not start with postgresql, which if I understand correct already supports getting ids in bulk_create. I think the "how to support getting ids in MySQL" is a separate issue. Second, I strongly agree with Shai, falling back should either not happen at all, or need to be requested explicitly (a keyword to accept it that defaults to false). On Wednesday, March 30, 2016 at 5:07:21 PM UTC-6, Shai Berger wrote: > > On Tuesday 29 March 2016 13:19:01 Anssi Kääriäinen wrote: > > > > Personally I think we should just rename the method to fast_create() > > and allow it to fall back to single row at time behavior. This way you > > could safely call it for any objects on any database and know the > > results will be OK. I don't see much point in throwing errors when > > batch insert isn't possible. If batch insert isn't possible, the user > > needs to insert the values one row at a time in any case. > > > > I beg to differ. fast_create() as you described will be suitable for some > users, but if creating 2000 records is going to require 2000 database > roundtrips, I'd appreciate a way to be told about it already when I'm > testing > with 2. I could have other options to create the records (perhaps not > using > the ORM at all), or I could decide early that the backend is unsuitable > for my > needs. > > For some optimizations, it is OK to just drop them if you can't do them. > But > with bulk_create we could be talking about differences of orders of > magnitude. > It seems to me that with that premise, the decision that it's ok to drop > the > optimization should be explicit, and not Django's default. > > My 2 cents, > Shai. > -- 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/8eac26fc-9165-49ba-b044-5298f31354d3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Extend support for long surnames in Django Auth
On Sunday 31 July 2016 00:15:57 Donald Stufft wrote: > > On Jul 30, 2016, at 4:40 PM, Aymeric Augustin > > wrote: > > > > I have trouble believing that a significant number of people are used to > > typing 100+ characters when inputting their name into a website — let > > alone that a significant number of people have a last name that contains > > more than 100 characters and that isn’t a joke. How would it fit on a > > passport? > > See #6 of > https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about- > names/ > See #11 of this list. If we were to take it seriously, any name field should have an accompanying charset field. Or, actually, some substring-to-charset mapping, because of #10. Which makes one just go straight to #36. It isn't really a workable set of constraints. However, since you brought it up, and since it mentions names from the Klingon Empire, I would like to remind the supporters of MySQL-driven limits that for encodings which can express the full range of Unicode, including Klingon and Emoji, the MySQL limit is 191 and not 255. Just sayin'. Shai.
Re: Extend support for long surnames in Django Auth
On Sat, Jul 30, 2016 at 8:08 AM, Josh Smeaton wrote: > > I think having a single name field is reasonable for the vast majority of > cases, but it fails where projects really do need to identify two names for > things like sorting or categorising. I'd be willing to believe that a project requires storing names as an array of words for sorting. I can see how that would be helpful to do sorting. Even I have a full name of 5 words and I only use two of them because it's my culture. In this situation how to convince someone that it's not a waste of time to have to fill in several form fields, when they are going to the usage name they want anyway which is conceptualized rather as an array of words than a pair of words. Some people won't even want their real name on some projects. > I'd be willing to argue that if you did > need to differentiate between parts of a full name then you could customise > your User model to account for that. The issue is backward compatibility. We > can't just use migrations to remove the last name field because that would > break working code and potentially delete data. It'd break a lot more than > simply increasing the size of existing labels. Deporting the issue on the user project is an option, but I'd like to suggest that we keep on trying to find a curative solution for this issue which has been brought up on regularely. It should be possible to make a migration to add and provision the full name column and make first and last name column read-only if they exist - but not be provided on new projects. Even then, the backward incompatibility will be an easy fix, it's not like we were splitting data the other way, that would be a lot more difficult and require esoteric code, again, just like when we try to make people fit in two distinct inputs. Free users from our culture, open django.contrib.auth to the world. Rock'on James B) -- http://yourlabs.org -- 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/CALC3Kaf4K6yh0y-K8F2TdhTPs2h7DKQw9%2BO1xN5538gr4u1hDA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Extend support for long surnames in Django Auth
As I watch this discussion I am reminded of a talk I saw a few years ago at PyConAU: https://www.youtube.com/watch?v=_V4q0o-nKp4&list=PLs4CJRBY5F1KDIN6pv6daYWN_RnFOYvt0&index=33 -- Curtis On 01/08/16 09:34, James Pic wrote: On Sat, Jul 30, 2016 at 8:08 AM, Josh Smeaton wrote: I think having a single name field is reasonable for the vast majority of cases, but it fails where projects really do need to identify two names for things like sorting or categorising. I'd be willing to believe that a project requires storing names as an array of words for sorting. I can see how that would be helpful to do sorting. Even I have a full name of 5 words and I only use two of them because it's my culture. In this situation how to convince someone that it's not a waste of time to have to fill in several form fields, when they are going to the usage name they want anyway which is conceptualized rather as an array of words than a pair of words. Some people won't even want their real name on some projects. I'd be willing to argue that if you did need to differentiate between parts of a full name then you could customise your User model to account for that. The issue is backward compatibility. We can't just use migrations to remove the last name field because that would break working code and potentially delete data. It'd break a lot more than simply increasing the size of existing labels. Deporting the issue on the user project is an option, but I'd like to suggest that we keep on trying to find a curative solution for this issue which has been brought up on regularely. It should be possible to make a migration to add and provision the full name column and make first and last name column read-only if they exist - but not be provided on new projects. Even then, the backward incompatibility will be an easy fix, it's not like we were splitting data the other way, that would be a lot more difficult and require esoteric code, again, just like when we try to make people fit in two distinct inputs. Free users from our culture, open django.contrib.auth to the world. Rock'on James B) -- 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/c4e945a3-61bd-3917-dec5-9758b0d2790e%40tinbrain.net. For more options, visit https://groups.google.com/d/optout.
