Re: Value of tightening URLValidator/EmailValidator regular expressions?

> On 15 Mar 2016, at 03:51, Markus Holtermann wrote: > > I'd go with the HTML5 validator. Indeed, it would be a good idea to align the behavior of and Django’s validation. Currently a@b passes the former but not the latter. -- Aymeric. -- You received this

Re: Proposal: django.contrib.mysql

Wow I didn't reply for 11 days (sorry, company a bit crazy right now) and features are already being stolen merged! https://github.com/django/django/pull/6292/files :) > What's your main motivation for wanting to include it in Django itself? > I want Django to work better on MySQL/MariaDB

Status of DEP 0005: Improved middleware?

I like the improved middleware proposal: https://github.com/django/deps/blob/master/draft/0005-improved-middleware.rst What is the status of it? Is there an agreement under the django-core developers that the proposal is the right direction? Regards, Thomas Güttler -- You received this

Re: Status of DEP 0005: Improved middleware?

Here's the mailing list thread: https://groups.google.com/d/topic/django-developers/8LMJ44KAxWI/discussion I think mostly the implementation just needs to be completed. On Tuesday, March 15, 2016 at 10:32:15 AM UTC-4, guettli wrote: > > I like the improved middleware proposal: >

Re: Value of tightening URLValidator/EmailValidator regular expressions?

Is there a reason for having a backend validation at all? There is no reliable way to validate an email-address without actually sending a message to it. In my opinion EmailField should use a widget that uses `type="email"` to trigger frontend validation. It may also set a max length for the

[ GSOC 2016 ] providing standard interface for NoSQL databases

Hello, I would like to propose providing a standard interface for NoSQL databases . Some the points to consider are: 1. The *Fields *which are used to define the schema of the sql databases can also be used to provide in No sql databases. 2. In NoSQL dbs ,developers usually store

Re: Value of tightening URLValidator/EmailValidator regular expressions?

Validation that doesn't rely on browser behavior *is* useful, if only for the (admittedly shrinking, but still non-zero) population of folks using older browsers. Also API clients and so forth. Very much agreed that it should match the HTML5 spec, though - fewer edge cases and more predictable

ManyToManyField not generating ON DELETE CASCADE clauses on (default) through table

I have a query concerning the lack of a ON DELETE CASCADE clause to the foreign key constraints generated for PostgreSQL (using Django 1.8.11) on the default through tables generated for ManyToManyField. I was unable to find any related issues (”ManyToMany cascade” Search Results – Django

adding to documentation

Hi, I'm pretty new to Django, and am hugely interested in making it easier for folks to get into Django and to start contributing . I had a pretty terrible time both connecting my app to Postgres, and then deploying to Heroku, and needed a lot of help because of general documentation missing

Re: adding to documentation

Hi Becka - I'm glad you figured it out, and even happier that you'd like to contribute to making the docs better! Fixes to the docs where you found problems/errors are certainly welcome; you can do that in a ticket or a pull request, which ever you find easier. There's some information about how

Documentation for deployment on OpenShift Origin

Hi, OpenShift Origin is an Open Source PaaS system based on cool stuff like kubernetes, docker, ansible, golang ... developed mostly by RedHat. It's probably comparable to Heroku, but more flexible and completely Open Source (thanks RedHat !!). I use OpenShift every day, including for a few open

Re: [ GSOC 2016 ] providing standard interface for NoSQL databases

It sounds like by "NoSQL DBS" you mean specifically "Document store DBMS". Is this correct? (I'm sure most people know my rant about how "NoSQL" is a misnomer, and it's really "Non-relational" that people mean - it's not SQL per se they're avoiding, it's the relational model) The

Re: Documentation for deployment on OpenShift Origin

Does OpenShift have some suitable docs you can contribute to? I don't think the Django docs are the right place for specific deployment scenarios like this. On Tuesday, March 15, 2016 at 5:42:31 PM UTC-4, is_null wrote: > > Hi, > > OpenShift Origin is an Open Source PaaS system based on cool

Re: Documentation for deployment on OpenShift Origin

Perhaps, should we also start moving mod_python / uwsgi docs upstream ? -- 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: Documentation for deployment on OpenShift Origin

I don't mind maintaining the instructions for these common platforms and if Django's docs didn't have any deployment instructions that might be a bit odd. For what it's worth, the uwsgi docs do have some nice (at a very quick glance) looking instructions:

Re: Documentation for deployment on OpenShift Origin

Pretty nice docs they have nowadays I recon ! Perhaps we don't need documentation for all open source PaaS out there (ie. DEIS, the open source heroku-ish PaaS for CoreOs). Having at least one could help though. The only documentation about deploying django apps is in their blog and it's not

Re: Documentation for deployment on OpenShift Origin

I'd like to illustrate why I think having official documentation about deployment on PaaS would be great. What I mean by "there is confusion", is that IMHO on a PaaS SECRET_KEY should be managed by settings.py in an automatically created file in a private and persistent directory. For example:

Re: [ GSOC 2016 ] providing standard interface for NoSQL databases

It would also be worthwhile looking into the prior art on this topic. We had a GSoC project for non-relational data stores a few years back, and came to the conclusion that it probably wasn’t viable. You can dig into the archives to find out why. If you’re interested in adding non-relational

Re: Bringing some popular must have django tools/packages under django org umbrella

I recently got stuck upgrading a project to 1.9 due to a lot of useful packages being not maintained: - django-endless-pagination: a substitute for django-pagination while it didn't had python3 support - django-taggit-templatetags: from when django-tagging didn't had python3 support.