Support for database level on delete cascade 21961

2017-07-24 Thread Nick Stefan
Hi All,

I've taken interest to implimenting built in django support of ON DELETE 
CASCADE. As a general concept, the ticket was accepted 3 years ago, and 
there was some discussion around that time: 
https://code.djangoproject.com/ticket/21961 . I've put together a small PR 
with some but not all of the proposed design decisions, 
https://github.com/django/django/pull/8661. The original ticket proposed 
adding something like models.DB_CASCADE in addition to models.CASCADE, 
models.SET_NULL. That is the tact that I took in the PR.


At the time of the ticket there were some concerns:

1. Q: What do we do with models.DB_CASCADE when using a DB that doesn't 
support it? 
A: MySQL, PostgreSQL, SQLite3 and Oracle all now support this functionality.

2. Q: Won't it be confusing that signals will not fire? 
A: We can document that the application code mimics models.DO_NOTHING, no 
signals will fire, and that all the deletion will be handled by SQL.

3. Q: Won't it be confusing that models.DB_CASCADE won't trigger a foreign 
model's models.CASCADE?
A: Is it any different than having a models.DO_NOTHING table pointing to a 
models.CASCADE table? We can document that on the application side, 
models.DB_CASCADE works like models.DO_NOTHING.

4. Q: generic foreign keys?
A: We could forbid models.DB_CASCADE on these types of relations?

5. Q: implicit foreign keys between child to parent in model inheritance?
A: We could forbid models.DB_CASCADE on these types of relations?


Additionally there was a proposal by Carl Meyer to split out database based 
delete into a separate kwarg. To summarize: 
ForeignKey(on_delete=models.CASCADE) versus 
ForeignKey(on_delete_db=models.DB_CASCADE). This would help avoid having to 
implement a magical fallback mode when the DB didn't support 
models.DB_CASCADE. It also would help eliminate two very different code 
paths overloading the same kwarg.

My thoughts on the above splitting of the kwargs:
All of the django 2.0 databases can support ON DELETE CASCADE. So there's 
no longer any need for a magical fall back mode. There's also the added 
burden on explaining that we can only pass one of the two kwargs, and not 
use both at the same time. I think that favors overloading a single kwarg.

Simon Charrette made a suggestion to make the models.CASCADE, 
models.SET_NULL, models.DB_CASCADE, etc all inherit from an OnDelete class. 
This allows the old application callables to still be simple callables, new 
SQL based operations such as DB_CASCADE to access an as_sql method, and yet 
both be instances of the same class for migration serialization. 


Seeking feedback,
Nick

-- 
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/20f67b4e-bf5b-4c55-bcc8-aac41cfae598%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Future of the development server's auto-reloading

2017-07-24 Thread Tom Forbes
I was looking into refactoring the auto-reloading code and I wanted to 
gather some feedback. There is some potential to squash several bugs in one 
go[1][2][3].

To begin with we can get rid of the Jython specific code, Jython is 2.7 
only at the moment and I don't think that will change soon.

We currently have an implicit dependency on `pyinotify`, if it's installed 
a more efficient inotify-based watcher is used. I've never seen this 
advertised anywhere, and pyinotify has not received any updates in over 3 
years. There is also this[4] blog post which says perhaps pyinotify isn't 
the best. I think the best way forward is to use the 'watchdog' package if 
it's installed, as it contains platform-specific implementations for 
observing file modifications[6] and even their fallback polling observer[7] 
is better than any we could include in Django. If we want to add the 
ability to use the watchman service with Django (something I fully agree 
with) perhaps adding support for it directly to that library would be more 
preferable than bundling it in Django itself.

The current autoreloading code contains some translations specific code 
that would be good to split out. It would be nice to have the autoreload 
module be as focused as possible on just detecting and handling file 
changes in a pretty neutral way, other parts of Django could register 
subscriptions to be notified when files change and can handle it themselves 
(perhaps via signals?). For example the cached template loader could 
register a callback to fire whenever one if it's source files changes and 
delete that entry from the cache, the translations framework could handle 
.mo files changing itself or third party modules can use these hooks to do 
whatever crazy things they want.

I've got a first-draft branch with a cleanup of the autoreload code 
here[8], any feedback would be welcome. It currently doesn't handle syntax 
error reloading or the i18n resetting. Could the syntax error reloading be 
improved with a clean re-implementation of the autoreloader? I can't think 
of any nice ways to handle it.

1. https://code.djangoproject.com/ticket/27685#ticket
2. https://code.djangoproject.com/ticket/25624
3. https://code.djangoproject.com/ticket/25791
4. 
http://www.serpentine.com/blog/2008/01/04/why-you-should-not-use-pyinotify/
5. 
https://pythonhosted.org/watchdog/_modules/watchdog/observers/polling.html
6. https://pythonhosted.org/watchdog/api.html#module-watchdog.observers
7. 
https://pythonhosted.org/watchdog/_modules/watchdog/observers/polling.html
8. 
https://github.com/orf/django/blob/27685-autoreloader-refactor/django/utils/autoreload.py

-- 
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/b33d73e3-6ff5-431d-b9ff-7db1219d11cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Proposal: provide postgresql powered full-text search in djangoproject.com

2017-07-24 Thread Aymeric Augustin
> On 11 Jul 2017, at 12:49, Jannis Leidel  wrote:
> 
>> On 12. May 2017, at 11:42, Aymeric Augustin 
>>  wrote:
>> 
>> These features are desirable and easy to configure with ES, but that wasn't 
>> done, perhaps for lack of familiarity with ES.
> 
> It was not out of lack of familiarity with ES but lack of time when we worked 
> on the redesign and first fundraiser round, two years ago. Gratis. In our 
> spare time (https://github.com/django/djangoproject.com/pull/303 
>  et al).
> 
> You of all people should know that comments like that are hurtful as they 
> imply we just didn’t care enough to learn ES. But in fact both Tim and Honza 
> (an elastic employee) reviewed the code and made lots of suggestions.

Yes, I should know better. Please accept my apologies.

In my own experience with ES, the learning curve is rough. It can take hour or 
days to figure out how to optimize a single line of configuration. That's what 
I had in mind when I said "familiarity". To be honest, the bigger problem in 
that sentence is "easy to configure"... Anyway: I'm sorry.

Best regards,

-- 
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/4BF5DB0C-02B7-46C4-92E0-20DA00859F7F%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.