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

[Matías Iturburu]

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.

django-registration was another must have that recently resurfaced but the
same situation spawned django-registration-redux.

Would it be too much a hassle to open an django-contrib organization with
less friction provide support for orphaned projects?

2015-11-24 16:27 GMT-03:00 Marc Tamlyn :

> This is something the core team discussed in Amsterdam. I believe there
> was consensus to trial it with Django registration. I should catch up with
> James and see if it is transferred. If this goes well I see no reason why
> not.
>
> The biggest problem is the selection of packages, we have historically
> wanted to avoid too much bikeshedding. Initially it's likely to be mostly
> relatively inactive small utilities I think. But I think we are open to
> being more risky here.
>
> M
> On 24 Nov 2015 7:02 pm, "Asif Saifuddin"  wrote:
>
>> The projects will have the official tool status + the maintainer of the
>> projects will be able to collaborate better with django core team? less
>> risk of being abandoned by the maintainers etc.
>>
>> IMHO
>>
>> On Wed, Nov 25, 2015 at 12:31 AM, Collin Anderson 
>> wrote:
>>
>>> Hi,
>>>
>>> Say a little bit more: What would be the goal? What would you hope would
>>> be accomplished by doing this?
>>>
>>> Thanks,
>>> Collin
>>>
>>> On Tuesday, November 24, 2015 at 1:27:11 PM UTC-5, Asif Saifuddin wrote:

 How is the idea? tools like django-debug-toolbar, django-silk,
 django-taggit, django-filter etc and some more de facto tools under the
 umbrella of django github org?

 Regards

>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/django-developers/bIzfHebE2sw/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, 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/70062405-3ccd-49b2-9118-ec1679203cd1%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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAKAqTgrnMoqy-%3DdDUx31Dgru6XTzT3e-T%3DhspY-CDK5tV9k1gQ%40mail.gmail.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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMwjO1FzQ8cCgF7pR%2BRtPiSkNc5W4ipeWfwLz0hi4q_xzxZoAQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Matías Iturburu
http://www.linkedin.com/in/tutuca | http://ltmo.com.ar

-- 
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

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

[Russell Keith-Magee]

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 support to Django, my
inclination is that you’ll get more traction proposing a specific backend -
I outlined what would be involved in my DjangoCon US talk last year:

https://www.youtube.com/watch?v=VgM0qmpHDiE

Yours,
Russ Magee %-)

On Wed, Mar 16, 2016 at 5:50 AM, Curtis Maloney  wrote:

> 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 NoSQL/Non-rel name is really too vague, as it covers "anything that's
> not SQL / Relational"... which can cover key/value, document, graph, log,
> and even filesystem or email, when it comes down to it.
>
> I think it will help if you clarify what model you _do_ target, not which
> you do _not_.
>
> All that said/vented, I agree it would be nice to have a common
> abstraction layer atop various document stores.  The trick now will be
> finding sufficient commonalities.
>
> I feel that the ORM's relation-span/transforms/lookups syntax would be
> equally viable on nested documents.
>
> One of the benefits of an abstraction layer is allowing other tools to
> generically interact with these new objects.  What plans do you have for
> how to support non-flat documents in, for instance, Forms?
>
>
> --
> Curtis
>
> On 16/03/16 05:29, girish ramnani wrote:
>
>>
>> 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 data in denormalized form. so
>> in two related collections a meta tag /denormal = True /can be
>> provided. Which would make that collection a child of the other
>> model ( related ). In normal scenario the collections will be
>> connected using _id used as a foreign key.
>>  3. providing contrib.mongo with Field such as GridFSField for providing
>> support for GridFS
>>  4. considering the database transaction transaction blocking ( PyMongo
>> provides blocking api for mongo )
>>  5. creating Mixins such as /FlexibleMixin /which would allow Models to
>> have dynamic fields. i.e directly insert fields which are not listed
>> in the Model schema.
>>
>>
>> there are lot more things (Migrations, settings etc) to consider but
>> before that needed to know that I am going in the right direction or
>> not?. Please suggest.
>>
>> --
>> 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/b2477318-9252-4241-a9fe-0972acb1b1cf%40googlegroups.com
>> <
>> https://groups.google.com/d/msgid/django-developers/b2477318-9252-4241-a9fe-0972acb1b1cf%40googlegroups.com?utm_medium=email&utm_source=footer
>> >.
>> 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/56E88390.40005%40tinbrain.net
> .
>
> 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/CAJxq84_UfN8OO

Re: Documentation for deployment on OpenShift Origin

[James Pic]

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:

https://github.com/political-memory/political_memory/blob/master/memopol/settings.py#L38-L46

You might be tempted to store it in an environment variable, but
that's not safe because environment variables are dumped in deployment
logs, like in their first example:

https://github.com/openshift/django-ex/blob/master/project/settings.py#L24-L28

In their other example (oh I found out they have two examples, more
confusion for users !), they use some sort of system to store the
secret key in a json file, that's a lot more complicated than it
should:

https://github.com/openshift/django-example/blob/master/wsgi/myproject/myproject/settings.py#L19-L28

By more complicated, I mean that it doesn't even work because it uses
a module that's not even in the repo anymore, so that won't even work.

For DEBUG, there's one example where they do DEBUG =
os.environ.get('DEBUG') == True, what happens if DEBUG is not set as
an environment variable ?

For static files, it's a bit more complicated on PaaS because you get
one persistent directory, where you want MEDIA_ROOT to be, and one
public directory, which is not served by the httpd. Their
configuration doesn't even include MEDIA_ROOT support BTW, again
there's only one way that works IMHO it's to symlink media from the
persistent dir into the "public" dir, and have STATIC_ROOT in a subdir
of the public dir - which again is not what they have.

And I could go on like this for a while heheh

Anyway, I'll try to contribute a new page about Django in the
devcenter repo ( https://github.com/openshift/devcenter ) and hope
they will want to merge it else I'll ask here again and as last resort
post it on my blog which I can't even get on djangoplanet even though
I asked several times in the past yearS.

Best ;)

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

Re: Documentation for deployment on OpenShift Origin

[James Pic]

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 very good: it assumes the reader knows OpenShift very
well already on one hand, and it doesn't do Django very well on the
other hand (confused staticfiles configuration for example). A
documentation targeted at Django users who want to try to deploy on
OpenShift is missing IMHO.

I'm already doing some PRs to fix their example project which is the
official only thing I could find they have that would relate to
documentation so far, I also asked on their IRC channel if there's
anywhere I could contribute actual documentation.

Thanks for your feedback !

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

Re: Documentation for deployment on OpenShift Origin

[Tim Graham]

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: 
https://uwsgi-docs.readthedocs.org/en/latest/tutorials/Django_and_nginx.html

On Tuesday, March 15, 2016 at 6:37:45 PM UTC-4, is_null wrote:
>
> 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 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/1b18a402-593a-4fed-9e26-2d76ef087325%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Documentation for deployment on OpenShift Origin

[James Pic]

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 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/CALC3KaevEWQ-PHGMQfuaxPL%3D29tCOJQYR1QmzyPLGWGjQ4%2BJKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Documentation for deployment on OpenShift Origin

[Tim Graham]

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 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 source projects 
> such as the political-memory project (mempol and compotista) and 
> django-autocomplete-light's test_project which are deployed by travis 
> when tests succeed. It's really changed my life as a django developer 
> and I'd like to share it with the community (reminds me about my post 
> on uWSGI on this list in 2011 heh). 
>
> I'd like to contribute documentation about deployment of Django 
> projects on OpenShift, would that be useful ? 
>
> Thanks 
>
> Best 
>
> -- 
> 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/db1b2ffc-5954-43ac-b472-95c00c527adc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Curtis Maloney]

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 NoSQL/Non-rel name is really too vague, as it covers "anything 
that's not SQL / Relational"... which can cover key/value, document, 
graph, log, and even filesystem or email, when it comes down to it.


I think it will help if you clarify what model you _do_ target, not 
which you do _not_.


All that said/vented, I agree it would be nice to have a common 
abstraction layer atop various document stores.  The trick now will be 
finding sufficient commonalities.


I feel that the ORM's relation-span/transforms/lookups syntax would be 
equally viable on nested documents.


One of the benefits of an abstraction layer is allowing other tools to 
generically interact with these new objects.  What plans do you have for 
how to support non-flat documents in, for instance, Forms?



--
Curtis

On 16/03/16 05:29, girish ramnani wrote:


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 data in denormalized form. so
in two related collections a meta tag /denormal = True /can be
provided. Which would make that collection a child of the other
model ( related ). In normal scenario the collections will be
connected using _id used as a foreign key.
 3. providing contrib.mongo with Field such as GridFSField for providing
support for GridFS
 4. considering the database transaction transaction blocking ( PyMongo
provides blocking api for mongo )
 5. creating Mixins such as /FlexibleMixin /which would allow Models to
have dynamic fields. i.e directly insert fields which are not listed
in the Model schema.


there are lot more things (Migrations, settings etc) to consider but
before that needed to know that I am going in the right direction or
not?. Please suggest.

--
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/b2477318-9252-4241-a9fe-0972acb1b1cf%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/56E88390.40005%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Documentation for deployment on OpenShift Origin

[James Pic]

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 source projects
such as the political-memory project (mempol and compotista) and
django-autocomplete-light's test_project which are deployed by travis
when tests succeed. It's really changed my life as a django developer
and I'd like to share it with the community (reminds me about my post
on uWSGI on this list in 2011 heh).

I'd like to contribute documentation about deployment of Django
projects on OpenShift, would that be useful ?

Thanks

Best

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

Re: adding to documentation

[Jacob Kaplan-Moss]

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 to contribute to the documentation here:
https://docs.djangoproject.com/en/1.9/internals/contributing/writing-documentation/

The Heroku-specific stuff, though, is a bit problematic for Django's
official docs. We've generally shied away from calling out specific
commercial services in our official documentation. Those things can be read
as endorsements, and we don't want to be in the practice of endorsing
specific services. We'd prefer to leave that sort of thing up to the
company in question (and indeed in this case Heroku's got a quite good
guide over in their documentation). Changing that stance isn't impossible,
but it probably involves a larger discussion than you might want to start
at this point! So if you want to document the Heroku-specific stuff, I'd
recommend you put that elsewhere, perhaps on your own site.

Thanks,

Jacob

On Tue, Mar 15, 2016 at 2:02 PM, Becka  wrote:

> 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 online, or being very very hard to find.  The steps
> outlined in some tutorials are hugely inaccurate, and it's impossible to
> know which ones to use when starting out.
>
>  The psycopg2 package documentation wasn't helpful enough as a manual, and
> I wound up making mistakes that I wasn't able to undo or even figure out,
> since I was working on my own.  I'm lucky to live in San Francisco, where
> help is easy to find.
>
> Now that I've gone through the process though, I'd like to add this to the
> tutorial, as well as the steps to deploying on Heroku.  Are these within
> the scope of a Django ticket?
>
> Thanks,
>
> Becka
>
> --
> 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/CANOxe%2B1JBcS4LW-auzp85_a%3Dko1YYKKjF8mr904c_rJsqSvPGw%40mail.gmail.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/CAK8PqJFFJcXizbjdOePD2LgrrZH7Q%3DG0x3jSzRaqyU%3D-w%3D0ZRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

adding to documentation

[Becka]

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 online, or being very very hard to find.  The steps
outlined in some tutorials are hugely inaccurate, and it's impossible to
know which ones to use when starting out.

 The psycopg2 package documentation wasn't helpful enough as a manual, and
I wound up making mistakes that I wasn't able to undo or even figure out,
since I was working on my own.  I'm lucky to live in San Francisco, where
help is easy to find.

Now that I've gone through the process though, I'd like to add this to the
tutorial, as well as the steps to deploying on Heroku.  Are these within
the scope of a Django ticket?

Thanks,

Becka

-- 
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/CANOxe%2B1JBcS4LW-auzp85_a%3Dko1YYKKjF8mr904c_rJsqSvPGw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Carlton]

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 
)
 
so I thought I’d ask before I open a ticket. 


I create an app called constraints in which I define two models: 


from django.db import models
class A(models.Model):
 name = models.CharField(max_length=200)

class B(models.Model):
 name = models.CharField(max_length=200)
 a_set = models.ManyToManyField(A, db_constraint=True)


I then inspect the generated SQL:

$ ./manage.py sqlall constraints

BEGIN;

CREATE TABLE "constraints_a" (

"id" serial NOT NULL PRIMARY KEY,

"name" varchar(200) NOT NULL

)

;

CREATE TABLE "constraints_b_a_set" (

"id" serial NOT NULL PRIMARY KEY,

"b_id" integer NOT NULL,

"a_id" integer NOT NULL REFERENCES "constraints_a" ("id") DEFERRABLE 
INITIALLY DEFERRED,

UNIQUE ("b_id", "a_id")

)

;

CREATE TABLE "constraints_b" (

"id" serial NOT NULL PRIMARY KEY,

"name" varchar(200) NOT NULL

)

;

ALTER TABLE "constraints_b_a_set" ADD CONSTRAINT "b_id_refs_id_4308660a" 
FOREIGN KEY ("b_id") REFERENCES "constraints_b" ("id") DEFERRABLE INITIALLY 
DEFERRED;

CREATE INDEX "constraints_b_a_set_b_id" ON "constraints_b_a_set" ("b_id");

CREATE INDEX "constraints_b_a_set_a_id" ON "constraints_b_a_set" ("a_id");

COMMIT;


For the table constraints_b_a_set I am expecting the two foreign key 
constraints to include an ON DELETE CASCADE:

   - "a_id" integer NOT NULL REFERENCES "constraints_a" ("id") ON DELETE 
   CASCADE ... 
   - ALTER TABLE "constraints_b_a_set" ADD CONSTRAINT 
   "b_id_refs_id_4308660a" FOREIGN KEY ("b_id") REFERENCES "constraints_b" 
   ("id") ON DELETE CASCADE ... 

I came across this running DELETE FROM ... SQL statements against a Django 
generated database. 


Using the example models if I run DELETE FROM "constraints_a";` (with 
related objects in place) I get an error:


ERROR: update or delete on table "constraints_a" violates foreign key 
constraint "" on table "constraints_b_a_set" 

DETAIL: Key (id)=(1) is still referenced from table "constraints_b_a_set".


This is because the lack of the ON DELETE CASCADE means the through table 
record is not removed when the referenced row is deleted. 


For me this looks like a bug. *First question then is, is it a bug?* Or is 
it by design, and something that just needs working around? Does it need 
documenting? 


Second (related) question is, would anything break if I just added the 
constraint in SQL myself? 


I can work around this by an additional query to DELETE FROM the through 
table, and — whilst there’s a lot of logic there that made my head hurt 
— it looks as if Django does this in django/django/db/models/deletion.py — 
but it would be nice to let the database handle the constraint if possible. 


Would Django’s own logic break if we pushed it to the database level — or, 
conversely, is there room to do that? 


I’m happy to spend time on it.


(No doubt, having raised it, the answer will be, *“No, not bug; not open to 
change, and documented HERE”* 😀)


Thanks for the input/guidance. 


Kind Regards, 


Carlton

-- 
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/fbcd7bd1-4376-4006-8fa1-3dfea310fb37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Value of tightening URLValidator/EmailValidator regular expressions?

[Kevin Grinberg]

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 behavior.


On Tuesday, March 15, 2016 at 12:42:17 PM UTC-4, Joakim Saario wrote:
>
> 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 database column. Nothing more.
>
> Den måndag 14 mars 2016 kl. 19:09:24 UTC+1 skrev Tim Graham:
>>
>> On a pull request that proposes to tighten the validation of 
>> EmailValidator [0], Ned Batchelder questioned the usefulness of this:
>>
>> "Can I respectfully suggest that continuing to tweak this complex regex 
>> to get asymptotically closer to perfection is not worth it? Especially to 
>> fix false positives. What real-world problem is happening because 
>> "gmail.-com" is accepted? "gmail.ccomm" is also accepted, but is just as 
>> useless as an email address."
>>
>> Collin Anderson proposed:
>>
>> "I think we should try to just match the standard html > type="email"> validation. I'd imagine that most uses cases would want to 
>> match that. We might be able to use the regex verbatim from the standard 
>> itself:
>>
>> ​
>> https://html.spec.whatwg.org/multipage/forms.html#e-mail-state-(type=email
>> )
>> If people want to allow things outside of that they could use a custom 
>> regex.
>> Though it gets more complicated when considering Unicode. Unicode needs 
>> to get normalized to ascii before running through the official regex."
>>
>> (Of course, this may be somewhat backwards-incompatible.)
>>
>> What are your thoughts on this? I don't mind putting a halt to 
>> enhancements to the validation as long as we can articulate a sensible 
>> policy in the documentation.
>>
>> [0] https://github.com/django/django/pull/5612
>>
>

-- 
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/c6b3fc10-7a7e-4f91-a54d-9b4ae45c755e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ GSOC 2016 ] providing standard interface for NoSQL databases

[girish ramnani]

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 data in denormalized form. so 
   in two related collections a meta tag *denormal = True *can be provided. 
   Which would make that collection a child of the other model ( related ). In 
   normal scenario the collections will be connected using _id used as a 
   foreign key.
   3. providing contrib.mongo with Field such as GridFSField for providing 
   support for GridFS
   4. considering the database transaction transaction blocking ( PyMongo 
   provides blocking api for mongo )
   5. creating Mixins such as *FlexibleMixin *which would allow Models to 
   have dynamic fields. i.e directly insert fields which are not listed in the 
   Model schema.


there are lot more things (Migrations, settings etc) to consider but before 
that needed to know that I am going in the right direction or not?. Please 
suggest.

-- 
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/b2477318-9252-4241-a9fe-0972acb1b1cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Value of tightening URLValidator/EmailValidator regular expressions?

[Joakim Saario]

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 database column. Nothing more.

Den måndag 14 mars 2016 kl. 19:09:24 UTC+1 skrev Tim Graham:
>
> On a pull request that proposes to tighten the validation of 
> EmailValidator [0], Ned Batchelder questioned the usefulness of this:
>
> "Can I respectfully suggest that continuing to tweak this complex regex to 
> get asymptotically closer to perfection is not worth it? Especially to fix 
> false positives. What real-world problem is happening because "gmail.-com" 
> is accepted? "gmail.ccomm" is also accepted, but is just as useless as an 
> email address."
>
> Collin Anderson proposed:
>
> "I think we should try to just match the standard html  type="email"> validation. I'd imagine that most uses cases would want to 
> match that. We might be able to use the regex verbatim from the standard 
> itself:
>
> ​
> https://html.spec.whatwg.org/multipage/forms.html#e-mail-state-(type=email
> )
> If people want to allow things outside of that they could use a custom 
> regex.
> Though it gets more complicated when considering Unicode. Unicode needs to 
> get normalized to ascii before running through the official regex."
>
> (Of course, this may be somewhat backwards-incompatible.)
>
> What are your thoughts on this? I don't mind putting a halt to 
> enhancements to the validation as long as we can articulate a sensible 
> policy in the documentation.
>
> [0] https://github.com/django/django/pull/5612
>

-- 
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/b4e1b9d9-c424-438b-a66b-21339bebb702%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Status of DEP 0005: Improved middleware?

[Tim Graham]

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: 
> 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 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/d1172646-8151-4526-8713-a6cc6be7dfa8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Status of DEP 0005: Improved middleware?

[guettli]

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 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/fd710db7-b4f0-4ef0-b461-4d50b0948327%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: django.contrib.mysql

[Adam Johnson]

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
 

> Do you have a long term interesting in maintaining the module as part of 
> Django itself?
>

I've worked with Django on MySQL for 3 years and don't see that ending any 
time soon.
 

> we have Python’s “standard library is where modules go to die” problem
>

I'm aware of this, and as you suggest Aymeric, we could just merge the most 
stable bits. I was thinking anything that's similar to what 
contrib.postgres supplies is a good idea for inclusion - the fields, 
lookups, and aggregates are good ideas. Of the fields I think only the 
JSONField and maybe EnumField are worth it.

Also the migration operations for loading plugins might be useful, although 
they're mostly only useful on MariaDB.

For writing a DEP - I just make a PR to https://github.com/django/deps 
right?

I'm happy for JSONField to be made a core field on the condition that it's 
> underlying support is more than a text blob on all our main databases. It 
> sounds like this will soon be the case.
>

 Just a warning - I think this would be a very complex field, with lots of 
internal connection vendor switching. All the DB vendors have done it their 
own way, more or less :( 


On Friday, March 4, 2016 at 9:15:02 AM UTC, Marc Tamlyn wrote:
>
> One of the other reasons why contrib.postgres is in core is that it 
> required some changes to internals of the ORM. It's possible that all of 
> those we need are done now (except custom indexes) - is there anything 
> about contrib.mysql which would benefit from this?
>
> I'm happy for JSONField to be made a core field on the condition that it's 
> underlying support is more than a text blob on all our main databases. It 
> sounds like this will soon be the case.
>
> Marc
>
> On 4 March 2016 at 09:04, Josh Smeaton > 
> wrote:
>
>> I agree regarding choosing the most most useful bits. When we discussed 
>> this at DUTH I did mention that there were some features that would be very 
>> difficult to get included in Django. I guess you'd have to consider whether 
>> or not you'd be willing to move features from django-mysql into contrib and 
>> how that might affect django-mysql in the longer term.  I really like the 
>> idea of having a contrib.mysql though, as it shows we're not just committed 
>> to moving postgres forward. Having a voice for mysql in the team would also 
>> be very helpful.
>>
>> Cheers
>>
>> On Friday, 4 March 2016 18:15:15 UTC+11, Aymeric Augustin wrote:
>>>
>>> Hi Adam,
>>>
>>> django-mysql has a rather large API surface. I think the first step 
>>> would be to make a list of the most stable and generally useful bits that 
>>> are candidate for inclusion in Django and to write that list down in a DEP.
>>>
>>> The fields, functions, lookups, and aggregates are good candidates. I’m 
>>> less sure about the QuerySet extensions because we don’t have anything 
>>> similar yet. We’d have to think about the implications.
>>>
>>> Looking forwards, django-mysql could be an experimental ground for 
>>> features. When they stabilize, the most common features could go into 
>>> django.contrib.mysql.
>>>
>>> Since making changes to public APIs is a pain, you only want to put code 
>>> in Django when it’s done. To a lesser extent, we have Python’s “standard 
>>> library is where modules go to die” problem.
>>>
>>> It would obviously help if other community members expressed interest in 
>>> django.contrib.mysql or, even better, intent to help maintain it in the 
>>> future.
>>>
>>> I hope this helps,
>>>
>>> -- 
>>> Aymeric.
>>>
>>> PS: if this plan comes to fruition, most likely you’ll get commit access 
>>> along the way ;-)
>>>
>>>
>>> On 04 Mar 2016, at 00:09, Adam Johnson  wrote:
>>>
>>> The *django.contrib.postgres* docs state:
>>>
>>> There is no fundamental reason why (for example) a contrib.mysql module 
 does not exist
>>>
>>>
>>> *Well...* over the past year and a bit I've been developing 
>>> Django-MySQL. It has a ton of features specific to MySQL and/or MariaDB. 
>>> For a quick tour of the features, see the exposition in the documentation: 
>>> https://django-mysql.readthedocs.org/en/latest/exposition.html (it's 
>>> not all suitable for Django core, some is kinda hacky (but well tested!))
>>>
>>> At DUTH in November I talked with Josh Smeaton about posting a 
>>> suggestion here for *django.contrib.mysql*. Since then, I've simply 
>>> been lazy/forgetful, but now I'm here getting round to it.
>>>
>>> I'm also a bit motivated by my recent completion of its *JSONField* for 
>>> MySQL 5.7+ which is very similar to the *contrib.postgres* one, copying 
>>> and adapting large parts of code from Marc Tamlyn's work. We all know how 
>>> much everyone loves JSON these days. If anything,

Re: Value of tightening URLValidator/EmailValidator regular expressions?

[Aymeric Augustin]

> 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 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/EB4E00EA-D1DD-4028-8F24-64C3EDF328A7%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.