Re: Having a MongoDB connector for Django

['Tom Evans' via Django developers (Contributions to Django itself)]

On Fri, Sep 15, 2017 at 6:44 PM, Nes Dis  wrote:
> I would like to thank everyone for their valuable comments. Simultaneously I
> would like to comment on some conceptions regarding using MongoDB. Its not
> accurate to state that relational joins cannot happen in MongoDB. It can be
> done at the application level. LEFT JOIN and INNER JOIN. A detailed
> description of this is available.

I don't think anyone has said that this cannot be done, but instead
that it is not desirable to do so.

A django ORM adapter that supports Mongo would be used by people who
would not understand that, whilst you can do relational things using
mongo, it will not perform well.

In an earlier email you said:

> 2) Use a completely new wrapper to deal with non-rel DBs
> That's a bit ridiculous, because now I have to reinvent Django ORM,
> contrib packages and everything under the sun.

This is precisely the problem. If a mongodb connector was provided for
Django's ORM, people would expect to be able to use it with all these
packages that are designed to work with relational databases, and will
be annoyed when the project is slow once real amounts of data are
added.

If you want relational data, use a relational database, and use an
object relational mapping API to access it. If you want document data,
use a document store, and use an object document mapping API to access
it (PyMongo provides an ODM).

If you want both, choose one as your primary data store (I prefer
relational), all changes go through there. On modifying the primary
store, update the secondary store, according to your business
requirements (eg, instantly, batched ETL, daily, etc)

Cheers

Tom

-- 
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/CAFHbX1K%2BfhRL7%3DJRmBXk_3aAyK_WYD7c44zn00gZGjJthBfr-A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Having a MongoDB connector for Django

['Tom Evans' via Django developers (Contributions to Django itself)]

Short answer: always use the appropriate tool

Relational databases and document stores have different uses and
purposes. Using a document store like a relational database (eg, with
an ORM (emphasis on the R)) is a bad idea, and using a relational
database as a document store is similarly foolish.

Work out what questions you want to ask of your data, then structure
the data in a way that allows you to query it efficiently.

If the format desired is a document store, I wouldn't attempt to
shoehorn that in to an ORM wrapper, I'd use something like mongothon.

Cheers

Tom

On Fri, Sep 8, 2017 at 8:50 AM, Nes Dis  wrote:
> Hello
>
> I am wondering what is the state of the art on Django having a backend
> connector for MongoDB database backend. There are a few solutions out there
> but they don't work as expected.
>
> A possible solution for this is to have a connector which translates SQL
> queries created in Django, into MongoDB queries.
>
> I would like to hear the expert opinion from the esteemed members of this
> group on this concept.
>
> A working solution for this can be found here: djongo. (Django + Mongo =
> Djongo) The project is hosted on github.
>
> Regards
> Nes Dis
>
> --
> 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/b0ce04d1-62cb-4765-b850-06c4a5b0607f%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/CAFHbX1%2BNpZuWrAgcMwkcJQ4Xg4TrM700JRsYV_AnW05_9L3joA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Automatic prefetching in querysets

['Tom Evans' via Django developers (Contributions to Django itself)]

Is this opt-{in,out} considered to be a global flag, meant to be
toggled on or off depending on whether it is an "expert" working on
the project or not?

I don't think that would be a good idea, almost all of our projects
have a mix of skill levels, and people move from team to team on a
regular basis. I don't think we have a project that has only been
worked on by senior developers or only worked on by junior developers.

What I think would be exceptionally useful would be to emit loud
warnings when developing (DEBUG=True or runserver) whenever this code
can detect that a prefetch MAY be applicable. A lot of our junior
developers are not as aware about DB structures and SQL performance
(particularly now that they don't design schemas and write DB
queries), so warnings as part of their normal development help trigger
teaching moments. Magically (sometimes) making things faster doesn't
teach them anything.

Turning this feature on/off per app is scary. If we're dealing with
models from AppA, we will get auto pre-fetching, but if we work with
models from AppB, we do not? If we're dealing with those models in the
same module, we will have different behaviour depending on which model
is being used? Please no.

I also think that it might be handy to specify
"qs.prefetch_related(auto=True)", or "with qs.auto_prefetch():", which
would then trigger the newly proposed behaviour. It's like "I want you
to prefetch all the things I use, but I don't know what just yet".
Having said that, I'd also like that to spit out a warning (again, dev
only) that specified what was actually prefetched, because why waste a
DB query in production to determine what we know whilst developing?

Cheers

Tom



On Wed, Aug 16, 2017 at 5:28 PM, Brice Parent  wrote:
> Le 16/08/17 à 14:07, Adam Johnson a écrit :
>>
>> I wouldn't want is to give free optimisations to non-ORM pros
>
>
> Something like 99% of django projects are by non-ORM pros, it can be easy to
> forget that on a mailing list of experts.
>
> I don't count myself as an ORM or SQL expert at all, but I've worked on at
> least 2 projects for which they had contracted such experts to optimise
> their projects once they reached some limits. Those experts only worked for
> them for a limited period of time, and if we changed this behaviour by
> default, I'm 100% sure they wouldn't understanding why their website was
> getting slower with the new release. And they would probably only see the
> performance issue on staging servers if they have some, or in production
> with a full database.
> I admit this can be a great thing for new comers and even small sites. But
> remember that, with or without this functionality, their website will need
> to be optimised in many ways when they start to have more users, and
> removing this 1+N common pitfall (or hiding the problem, as it is not
> completely solved as it's not the more efficient fix) will not be the only
> point they should look at.
> I think the solution for this would simply be to have it as opt-out, not to
> harm any already-working and optimised websites and allow to maintain a
> stable behaviour for 3rd party apps, but make it opt-in to new users just by
> pre-setting some setting in the settings.py file generated by "django-admin
> startproject". It could be a simple boolean setting or a list of apps for
> which we want the auto-fetch feature to be activated on. With this, new
> projects would be optimised unless they want to optimise manually, existing
> projects would still work without decreasing performance or creating memory
> problems in any case. Best of both worlds.
> And for existing non-optimised but existing websites, I prefer the
> status-quo than risking to create problems that might occur on production
> website.
> We could also, as proposed elsewhere in this thread, warn the developers (so
> only when settings.debug is set) when this kind of 1+N queries are executed
> that it could be way more efficient, either by activating the auto-fetch
> functionality or by manually prefetch related data.
>
> - Brice
>
> --
> 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/dc483976-f7d0-3aee-4f9e-76f515e5c761%40brice.xyz.
>
> 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 

Re: Time based one time password and django ?

['Tom Evans' via Django developers (Contributions to Django itself)]

Also django-two-factor, which builds on django-otp and provides all
extra bits you might need, eg setup views, QR code generation for
device registration, login wizards etc supporting HOTP/TOTP, static
tokens, Yubikey and SMS.

https://markusholtermann.eu/2016/09/2-factor-authentication-in-django/

Cheers

Tom

On Mon, Jan 16, 2017 at 4:38 PM, Alexander Dutton
 wrote:
> There's also , which is fairly easy
> to integrate into a Django project.
>
> As a long-term user of (but rare contributor to) Django I'd say the ease
> of using one of a number of third-party solutions points to keeping it
> out of core.
>
> Relatedly, integrating custom auth (i.e. not just username/password)
> would be easier if the Django admin site deferred to LOGIN_URL by
> default instead of presenting its own login form. An example issue is
> when one uses some sort of web server SSO module with
> RemoteUserMiddleware, and then the admin site presents asks for a
> username and password for already-authenticated non-staff (who have no
> local credentials).
>
> Yours,
>
> Alex
>
>
>
> On 16/01/17 16:28, Gavin Wahl wrote:
>> I have a project that implements TOTP and U2F as a third-party
>> package: https://github.com/gavinwahl/django-u2f
>>
>> On Sunday, January 15, 2017 at 3:47:56 AM UTC-7, ludovic coues wrote:
>>
>> Hello,
>>
>> After reading the recent thread on authentification in django, I
>> wondered about the chance of getting a 2-step auth mechanism in
>> django.contrib.
>>
>> Time based one time password, or TOTP, is now part of the RFC 6238.
>> For those who don't know it, it use a shared secret and current time
>> to produce 6 digit number. That number change every 30 seconds and is
>> used to confirm login after entering a correct username and password.
>>
>> As far as I can tell, there is no such thing present in django
>> currently. But I don't know if it's because nobody have done the  work
>> or if there are reason to not include 2-step solution in django.
>>
>> --
>>
>> Cordialement, Coues Ludovic
>> +336 148 743 42
>>
>> --
>> 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/7a3b3837-5c24-4984-abb8-d68d9ce31459%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/fb94cbfa-5987-4aa7-e74a-6fa53ce05cce%40alexdutton.co.uk.
> 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/CAFHbX1J02Kz62Th38x_USngaBQ-tKOd3DJH0OUyp4FFyMC879Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.0 Python version support (Python 3.6+ only?)

['Tom Evans' via Django developers (Contributions to Django itself)]

On Thu, Jan 5, 2017 at 8:10 PM, Asif Saifuddin  wrote:
> Hi,
>
> django 2.0 will be released in december 2017 and ubuntu 18.04 will be
> released in april 2018 which will default atleast 3.6, so I think this
> should also be taken as consideration while deciding.

I know supporting endless versions of python is not desirable, but
please bear in mind that some of us are in situations where what the
latest release of Ubunutu is not really relevant.

Our organisation uses CentOS 6, which is not EOL until the end of
2020. In CentOS 6, the stock version of python is python 2.6; we go
through special measures (EPEL) to get that up to python 2.7. If we
wanted to make the move to Python 3, we'd be talking about Python 3.4,
again through EPEL.

We have an infrastructure team responsible for provisioning servers,
and it is on their schedule that OS upgrades occur - it is not easy
for us as developers to argue that this team should spend significant
resource to upgrade to a later OS version or to roll custom python
RPMs.

Updating all of our codebase to Python 3 is going to be a pain for us,
it is hard to argue a business need with "Everything stays exactly the
same but is slightly more secure and easier to maintain".
Realistically, when we move to Python 3, it will be because the
supported Django LTS requires it. If we also have to jump through lots
of hoops to get the very latest Python 3 release, it won't make it
easier to argue, it will mean we are more likely to postpone it and
keep using old django versions, particularly on internal intranet
sites.

If there is a way that Python 3.4 support can be maintained without
significant detriment or penalty, this would be greatly appreciated by
those of us running more conservative enterprise distributions.

Cheers

Tom

-- 
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/CAFHbX1L%2BxkpR%3DJ6K%2BPTvD6OZT34ZPDgw62HXnUmi5BUrPOm5%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #27485 new New feature Allow ALLOWED_HOSTS to accept an IP-range / wildcard

['Tom Evans' via Django developers (Contributions to Django itself)]

On Sat, Nov 19, 2016 at 1:01 AM, Florian Apolloner
 wrote:
> On Thursday, November 17, 2016 at 5:07:07 PM UTC+1, Tom Evans wrote:
>>
>> Or:
>>   from socket import gethostname, gethostbyname
>>   ALLOWED_HOSTS = [ gethostname(), gethostbyname(gethostname()), ]
>
>
> That a) adds your hostname and b) (assuming you properly configured your
> system) 127.0.0.1  -- so as long as they are using 192.* to access the site,
> this does not help.

Our servers are configured such that "localhost" resolves to
127.0.0.1, and the hostname resolves to the local IP of the server.

I don't think our servers are in any way misconfigured, or configured
in a "special" manner - my laptop is configured in precisely the same
manner out of the box.

The offered solution works correctly on all of our development and
production servers, and also on our developers local machines running
various versions of Linux.

Cheers

Tom

-- 
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/CAFHbX1K_1dCLrMQm4cy0u1i1cnEzLJV%2Bb_1-p9n58ERV7%3Dghvg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #27485 new New feature Allow ALLOWED_HOSTS to accept an IP-range / wildcard

['Tom Evans' via Django developers (Contributions to Django itself)]

On Wed, Nov 16, 2016 at 10:29 PM, Thomas Turner  wrote:
> Hi
>
> The other day I raise a ticket to do with ALLOWED_HOSTS and it was suggested
> that I post on this group before creating a patch
> The ticket is https://code.djangoproject.com/ticket/27485
>
> The problem
>
> Now that Django 1.10.3 forces ALLOWED_HOSTS on with debug I have a problem.
> The problem is that when I developing I use an ip-address range of
> 192.168.1.*.
> The Ip-address can change depending on the computer I use.
> so I required the ability to add wildcard partly in an hostname.
> ie
> ALLOWED_HOSTS = ['192.168.1.*', '.mydomain.com']

Or:
  from socket import gethostname, gethostbyname
  ALLOWED_HOSTS = [ gethostname(), gethostbyname(gethostname()), ]

?

Cheers

Tom

-- 
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/CAFHbX1LndZK4DR7Lvqd3YeOBJoT33PpnGW-Vr84mF%3Ds1zdTQFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding an some warnings, checks, or exceptions for urls

['Tom Evans' via Django developers (Contributions to Django itself)]

On Mon, Apr 25, 2016 at 1:00 PM, Robert Roskam  wrote:
> I realize this is a really, really obvious and easily fixed newbie error.
> But here it is:
>
> urlpatterns = [
> url(r'^sitemap/',
> TemplateView.as_view(template_name='brochure/sitemap.html'),
> name="sitemap"),
> # More urls
> ]
>
> Sitemap should end with dollar sign.

The problem is that the url should *usually* end with a dollar sign.
There are valid use cases for a url not starting with a caret or
ending with a dollar.

Cheers

Tom

-- 
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/CAFHbX1JcWdZbdLs3HzD-z671tdDbXO2TU%3DQLf_UvjjRbySGYEw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Provide a way to pass kwargs when initializing the storage class

['Tom Evans' via Django developers (Contributions to Django itself)]

On Sat, Nov 7, 2015 at 11:58 AM, Raphaël Barrois
 wrote:
> Hello,
>
>
> The core of the proposed solution seems quite interesting; however, it also 
> introduces a new configuration format for backends.
>
> Caches and databases use a dict with a "BACKEND" key and an "OPTIONS" dict 
> for kwargs to pass to the backend.
> Likewise, entries in the TEMPLATES list are dicts with a "BACKEND" key and 
> various options.
>
>
> Do you think that the new setting should match these options instead of the 
> proposed two-tuples?

I like explicit:

STORAGE = {
'default': {
'ENGINE': 'path.to.foo.Storage',
'OPTIONS': { ..}
},
}

Cheers

Tom

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFHbX1JGG%2BJJStg%2BRK9ZZzXRi0zyi4QUjSLqQqNqoh1KGU2XnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #25582: Add a way to build URLs with query strings

['Tom Evans' via Django developers (Contributions to Django itself)]

On Fri, Oct 23, 2015 at 12:59 PM, guettli  wrote:
> API proposal:
>
> Add a new kwarg to reverse():
>
>reverse(..., get=None)
>
>
> Example: reverse('my_view_name', kwargs={'pk': '1'}, get=dict(param='value')

Would 'get' be a dict or a querydict? (URL parameters can be repeated,
dict keys cannot.)

Cheers

Tom

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFHbX1LmPAtgX1jykxYb-qx1eVn6ig4LLM96w0s0LNuomr7iTg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

['Tom Evans' via Django developers (Contributions to Django itself)]

On Tue, Sep 22, 2015 at 1:49 AM, Podrigal, Aron
 wrote:
> Different schemas?? Schema will always be different for each database
> backend according to its datatypes. I really don't understand what your
> concern is. In any case your free to specify a max_length=N where it will be
> the same for all backends.

This change would allow a django site running on postgres that you
could not dump the data from and reimport in to mysql without data
loss. It would make it easy to write non-portable apps without
thinking.

>
> While this makes sense, the use of TextField is also for the purpose of
> having rendered a text widget for ModelForms. So we should allow a
> max_length of None for both.
>

(I'm replying to two emails from you in one, hope that is alright)

No, TextField is used to designate an arbitrary length text field.
Having a widget.Textarea as the default input for this field is just a
default, it is perfectly correct to override the defaults either for
CharField or TextField to provide the desired widget type.

One should not be using models.TextField because a widget.Textarea is
desired for forms, instead it is to tell the database backend that the
column for this field should be an arbitrary length text type.

If the problem that is to be solved is that there is no easy way to
specify an arbitrary length text field that uses an input, this can be
solved with a very simple class:

class TextFieldWithInput(models.TextField):
def formfield(self, **kwargs):
defaults = {'widget': forms.TextInput}
defaults.update(kwargs)
return super(TextfieldWithInput, self).formfield(**defaults)

The main argument seems to be "Its a pain to think about the size of
my data when defining my database tables"; if we aren't thinking about
it then, then when do we think about it? Its kind of important..

Cheers

Tom

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFHbX1LbVfR4LdaqfF2S266dxhYRKA5B_dvbBA17c720spJKeA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

['Tom Evans' via Django developers (Contributions to Django itself)]

On Mon, Sep 21, 2015 at 5:21 PM, Paulo Maciel
 wrote:
> +1 max_length optional
>

I'm slightly worried from a DB point of view. Whilst blessed
PostgreSQL supports variable length fields seemingly without issues,
other DB engines (MySQL, for instance), have significant performance
issues using a TEXT field versus a VARCHAR field - particularly on
indexed fields, it must do a row read to retrieve data, rather than
use an indexed value.

Remember that VARCHAR columns can be fully indexed, whilst TEXT
columns can only have the first N (specified by user) characters
indexed, and reading the data will always require a row read, even if
the text is shorter than the indexed size.

In the ticket, it states that

"""
If I read the oracle docs correctly, specifying a length is mandatory
for VARCHAR2, and the maximum is 4000 bytes. For MySQL, it's 65K
bytes, for PostgreSQL and SQLite it's very large.
"""

For MySQL, it is 64k (65,535 bytes is *not* 65k!), and that is not the
whole story - 64k is the maximum record size - all your columns must
fit within that limit, not just one column in the record.

http://dev.mysql.com/doc/refman/5.7/en/column-count-limit.html

I'm slightly concerned as a MySQL/MariaDB user that this will lead to
"reusable" apps that are not performant on MySQL. Given that we
(generally) let Django define the database tables based upon models,
it seems much more important that the definition is correct and high
performing in all supported backends than to avoid choosing what
database columns you require in the tables - after all, that is what
the TextField is for, to allow the programmer to specify "this is an
arbitrary length text field".

I'm all for DB engines that support arbitrary length varchar fields to
use that when you specify a TextField. I'm very not keen on having
MySQL represent the majority of char fields as TEXT because no-one
could be bothered to specify the appropriate length.

Cheers

Tom

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFHbX1KnWTfw6Hk18Buu3hZOiHVB2RW4JNk_PFdaO_QoLK6CmA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Get current user in model signal pre_save

['Tom Evans' via Django developers (Contributions to Django itself)]

On Wed, Sep 9, 2015 at 4:11 PM, Xavier Palacín Ayuso
 wrote:
> I want to collects current user in model signal pre_save, to prevent remove
> super user permission to current super users.

Hi Xavier. This mailing list is for discussing the development of
django itself, not for discussing how to develop in django.

For help with developing in django, please use django-users mailing
list (and be patient - just because no-one has answered you in 6 hours
does not mean you should kick it up to django-developers).

Cheers

Tom

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFHbX1LmaqFniJr5gLMkfcewasCm6EW8nZjDpnMHan9jrSdndg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: request for API review of streaming responses additions

['Tom Evans' via Django developers (Contributions to Django itself)]

On Mon, Sep 7, 2015 at 3:04 PM, Aymeric Augustin
 wrote:
> 2015-09-07 10:00 GMT+02:00 Yann Fouillat :
>> I agree, do you know what tools could I use to emulate 3G ?
>
> As far as I know, the canonical tools are:
>
> - on Linux, netem:
> http://www.linuxfoundation.org/collaborate/workgroups/networking/netem
> - on OS X, Network Link Conditioner:
> https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/WhyNetworkingIsHard/WhyNetworkingIsHard.html
>

As well as these tools, there is similar functionality built in to the
chrom(e|ium) browser.

Inspect the page, toggle "Device mode" (click the phone icon next to
"Elements" tab), and options to throttle the network (with various
presets) will appear on the page.

I don't know a way to throttle network in chrome without also toggling
device emulation however, so the page will look different (within a
viewport).

Cheers

Tom

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFHbX1L70nEAhUSOovkjLBH0CyRxABx1yUCvcVwAz5k45DDJvg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.