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
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
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.
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
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
For what it's worth, the uwsgi docs do have some nice (at a very quick
glance) looking instructions:
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
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
On Tuesday, March 15, 2016 at 5:42:31 PM UTC-4, is_null wrote:
> OpenShift Origin is an Open Source PaaS system based on cool
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)
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
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
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
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
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
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
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
Here's the mailing list thread:
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:
I like the improved middleware proposal:
What is the status of it?
Is there an agreement under the django-core developers that the proposal is
the right direction?
You received this
Wow I didn't reply for 11 days (sorry, company a bit crazy right now) and
features are already being stolen merged!
> What's your main motivation for wanting to include it in Django itself?
I want Django to work better on MySQL/MariaDB
> 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.
You received this
Mail list logo