Re: Refactoring the autoreloader

2017-10-08 Thread Tim Allen 
If we need some dogfooding with real-world candidates, I'd be happy to 
provide some. We have a project which currently takes ~20 minutes to start 
up (automated data models created by introspecting a database) that might 
be a good edge-case candidate.

-- 
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/33edd13f-7867-4a0c-b834-fbee47e2f5b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PostgreSQL Partial Indexes package

2017-10-08 Thread Tim Allen 
I would love to see partial indexes supported. Great work! As far as 
databases with Django support:

- PostgreSQL supports partial indexes
- SQLite supports partial indexes
- SQL Server supports them, called "filtered indexes"
- Oracle: Sort of supports 
them: https://blog.jooq.org/2017/01/18/how-to-emulate-partial-indexes-in-oracle/
- MySQL/Maria/Drizzle: no support, AFAIK.

Would we want to build partial indexes in for all databases, with the 
caveat that they would be ignored on MySQL and perhaps Oracle? In those 
cases, would be default to a full index?

Regards,

Tim

On Saturday, October 7, 2017 at 4:56:00 AM UTC-4, Mattias Linnap wrote:
>
> Hi django-developers,
>
> I have written a package that implements PostgreSQL and SQLite partial 
> indexes on top of the new class-based indexes: 
> https://github.com/mattiaslinnap/django-partial-index
> The most common use case is partial unique constraints, but I have a few 
> projects where non-unique partial indexes have turned out useful as well.
>
> I have a few questions on how to continue with this:
>
> 1. Right now the "where condition" expression is provided as a string, and 
> has to be different for PostgreSQL and SQLite in some common cases (for 
> example boolean literals). Is there a good abstraction for SQL expressions 
> somewhere in Django internals that I could use instead, something similar 
> to Q-expressions perhaps? In particular, to add validate_unique() support 
> to ModelForms, I would need to be able to extract all fields that are 
> mentioned in the where condition.
> 2. I've seen mentions of a "check constraints" support being in 
> development (https://github.com/django/django/pull/7615). Will that 
> include partial unique constraints, or is just for the per-column checks?
> 3. If separate, then it would be nice to one day get partial indexes 
> merged into the contrib.postgres package. Do you have any suggestions on 
> what needs to happen before that - more test coverage, more contributors, 
> more users, or similar?
>
> Best,
>
> Mattias
>

-- 
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/df13ff66-8033-4f91-b49a-081bfa28db00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PostgreSQL Partial Indexes package

2017-10-08 Thread Adam Johnson 
It looks to me that the same trick on Oracle can be used on MySQL/MariaDB -
indexing a generated column. There's a comment on
https://mariadb.com/kb/en/library/generated-columns/ to that effect.

P.S. Drizzle is long dead, the site isn't even up any more :)

On 8 October 2017 at 12:38, Tim Allen  wrote:

> I would love to see partial indexes supported. Great work! As far as
> databases with Django support:
>
> - PostgreSQL supports partial indexes
> - SQLite supports partial indexes
> - SQL Server supports them, called "filtered indexes"
> - Oracle: Sort of supports them: https://blog.jooq.org/
> 2017/01/18/how-to-emulate-partial-indexes-in-oracle/
> - MySQL/Maria/Drizzle: no support, AFAIK.
>
> Would we want to build partial indexes in for all databases, with the
> caveat that they would be ignored on MySQL and perhaps Oracle? In those
> cases, would be default to a full index?
>
> Regards,
>
> Tim
>
> On Saturday, October 7, 2017 at 4:56:00 AM UTC-4, Mattias Linnap wrote:
>>
>> Hi django-developers,
>>
>> I have written a package that implements PostgreSQL and SQLite partial
>> indexes on top of the new class-based indexes: https://github.com/ma
>> ttiaslinnap/django-partial-index
>> The most common use case is partial unique constraints, but I have a few
>> projects where non-unique partial indexes have turned out useful as well.
>>
>> I have a few questions on how to continue with this:
>>
>> 1. Right now the "where condition" expression is provided as a string,
>> and has to be different for PostgreSQL and SQLite in some common cases (for
>> example boolean literals). Is there a good abstraction for SQL expressions
>> somewhere in Django internals that I could use instead, something similar
>> to Q-expressions perhaps? In particular, to add validate_unique() support
>> to ModelForms, I would need to be able to extract all fields that are
>> mentioned in the where condition.
>> 2. I've seen mentions of a "check constraints" support being in
>> development (https://github.com/django/django/pull/7615). Will that
>> include partial unique constraints, or is just for the per-column checks?
>> 3. If separate, then it would be nice to one day get partial indexes
>> merged into the contrib.postgres package. Do you have any suggestions on
>> what needs to happen before that - more test coverage, more contributors,
>> more users, or similar?
>>
>> Best,
>>
>> Mattias
>>
> --
> 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/df13ff66-8033-4f91-b49a-
> 081bfa28db00%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

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

Re: ModelForm unique validation is not done right IMHO.

2017-10-08 Thread Florian Apolloner 


On Saturday, October 7, 2017 at 5:07:31 PM UTC+2, Todor Velichkov wrote:
>
> I believe this could save a lot of headache to people. If there is no 
> guarantee that an instance cannot be saved after the form has been 
> validated, then do not give me an option to shoot myself into the foot.
>

Even if the whole instance were validated there is __never__ and can 
__never__ be any guarantee that the instance can actually be saved.


> My only concern here actually is not that we didn't know what will happen 
> (I think we know that), but how to show the user that the developer got 
> messed up, i.e. how to render an error for a field that is not rendered to 
> the user? Should this error be propagated to a NON-FIELD error or something 
> else?
>

Showing an error message which the user cannot correct because the field is 
not in the form is horrible UX.

I feel its perfectly fine to ask for a complete model instance at this 
> stage of the validation process (lots of methods got passed from the 
> beginning - form.clean() and instance.clean()).
>

I strongly disagree, especially for values which are set programmatically 
after validation (with the use of save(commit=False)) depending on values 
the user chose. Ie when the user chooses a category for a bug report and 
the code then automatically assigns another user as owner of that 
reuqest/ticket.

Cheers,
Florian

-- 
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/ac3fa5b6-ee22-465b-9cda-22387c547838%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Willing to contribute to Django

2017-10-08 Thread Shun Yu 
This the link you're looking for: https://code.djangoproject.com/

On Tuesday, October 3, 2017 at 10:41:28 PM UTC-7, Sai wrote:
>
> Hello Django developers,
>   I'm Sai. I'm using django from last 2 years. I worked with other 
> frameworks like Rails,Node. I'm very much attracted to django framework and 
> i would like to contribute to django features. I'm good in computer 
> networks and cryptography. Could some guide me on any features on which i 
> can work.
> Thanks
>
> Sai Phanindhra
>

-- 
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/dee6192c-067e-4836-bd4e-91261a39f233%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Failing to Run AutodetectorTests Using runtest.py (25253)

2017-10-08 Thread Shun Yu 
I'm trying to run the "migrations.test_autodetector.AutodetectorTests" for 
django, but I can't seem to get it to work.
I'm using Windows 10 and Python 3.6.2.
Below is the output I'm getting, thanks for the help!

C:\Users\Shun\.virtualenvs\django-original-test\Scripts\python.exe 
C:/Users/Shun/Desktop/django/django/tests/runtests.py 
--settings=test_sqlite tests.migrations.test_autodetector.AutodetectorTests
Testing against Django installed in 
'c:\users\shun\desktop\django\django\django'
Traceback (most recent call last):
  File "C:/Users/Shun/Desktop/django/django/tests/runtests.py", line 478, 
in 
options.exclude_tags,
  File "C:/Users/Shun/Desktop/django/django/tests/runtests.py", line 282, 
in django_tests
extra_tests=extra_tests,
  File "c:\users\shun\desktop\django\django\django\test\runner.py", line 
598, in run_tests
suite = self.build_suite(test_labels, extra_tests)
  File "c:\users\shun\desktop\django\django\django\test\runner.py", line 
484, in build_suite
tests = self.test_loader.loadTestsFromName(label)
  File 
"c:\users\shun\appdata\local\programs\python\python36\Lib\unittest\loader.py", 
line 153, in loadTestsFromName
module = __import__(module_name)
  File 
"c:\users\shun\desktop\django\django\tests\migrations\test_autodetector.py", 
line 18, in 
from .models import FoodManager, FoodQuerySet
  File "c:\users\shun\desktop\django\django\tests\migrations\models.py", 
line 9, in 
class ModelWithCustomBase(models.Model, metaclass=CustomModelBase):
  File "c:\users\shun\desktop\django\django\django\db\models\base.py", line 
108, in __new__
"INSTALLED_APPS." % (module, name)
RuntimeError: Model class tests.migrations.models.ModelWithCustomBase 
doesn't declare an explicit app_label and isn't in an application in 
INSTALLED_APPS.

Process finished with exit code 1


-- 
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/368001d5-2673-4716-8b7d-d0478d90e5da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Failing to Run AutodetectorTests Using runtest.py (25253)

2017-10-08 Thread Shun Yu 
When I try to run the whole test suite it works fine, it's just that when I 
try to run this specific one it's failing on me.

On Sunday, October 8, 2017 at 1:35:33 PM UTC-7, Shun Yu wrote:
>
> I'm trying to run the "migrations.test_autodetector.AutodetectorTests" for 
> django, but I can't seem to get it to work.
> I'm using Windows 10 and Python 3.6.2.
> Below is the output I'm getting, thanks for the help!
>
> C:\Users\Shun\.virtualenvs\django-original-test\Scripts\python.exe 
> C:/Users/Shun/Desktop/django/django/tests/runtests.py 
> --settings=test_sqlite tests.migrations.test_autodetector.AutodetectorTests
> Testing against Django installed in 
> 'c:\users\shun\desktop\django\django\django'
> Traceback (most recent call last):
>   File "C:/Users/Shun/Desktop/django/django/tests/runtests.py", line 478, 
> in 
> options.exclude_tags,
>   File "C:/Users/Shun/Desktop/django/django/tests/runtests.py", line 282, 
> in django_tests
> extra_tests=extra_tests,
>   File "c:\users\shun\desktop\django\django\django\test\runner.py", line 
> 598, in run_tests
> suite = self.build_suite(test_labels, extra_tests)
>   File "c:\users\shun\desktop\django\django\django\test\runner.py", line 
> 484, in build_suite
> tests = self.test_loader.loadTestsFromName(label)
>   File 
> "c:\users\shun\appdata\local\programs\python\python36\Lib\unittest\loader.py",
>  
> line 153, in loadTestsFromName
> module = __import__(module_name)
>   File 
> "c:\users\shun\desktop\django\django\tests\migrations\test_autodetector.py", 
> line 18, in 
> from .models import FoodManager, FoodQuerySet
>   File "c:\users\shun\desktop\django\django\tests\migrations\models.py", 
> line 9, in 
> class ModelWithCustomBase(models.Model, metaclass=CustomModelBase):
>   File "c:\users\shun\desktop\django\django\django\db\models\base.py", 
> line 108, in __new__
> "INSTALLED_APPS." % (module, name)
> RuntimeError: Model class tests.migrations.models.ModelWithCustomBase 
> doesn't declare an explicit app_label and isn't in an application in 
> INSTALLED_APPS.
>
> Process finished with exit code 1
>
>
>

-- 
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/c09e966f-70cb-4d2e-a305-43bb64fa3c02%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Willing to contribute to Django

2017-10-08 Thread phani p 
i'm looking for any tasks/projects to work in django. That link is way too
generic for me to pick.

On 9 October 2017 at 01:58, Shun Yu  wrote:

> This the link you're looking for: https://code.djangoproject.com/
>
>
> On Tuesday, October 3, 2017 at 10:41:28 PM UTC-7, Sai wrote:
>>
>> Hello Django developers,
>>   I'm Sai. I'm using django from last 2 years. I worked with other
>> frameworks like Rails,Node. I'm very much attracted to django framework and
>> i would like to contribute to django features. I'm good in computer
>> networks and cryptography. Could some guide me on any features on which i
>> can work.
>> Thanks
>>
>> Sai Phanindhra
>>
> --
> 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/dee6192c-067e-4836-bd4e-
> 91261a39f233%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Sai Phanindhra,
Ph: +91 9043258999

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

Re: ModelForm unique validation is not done right IMHO.

2017-10-08 Thread Todor Velichkov 
Settings values programmatically is a cumulative operation most of the 
time, however when its not and things depend on each other (like your 
example), then even the docs suggests than one can use the form.clean 
method. If there is some other dependency outside form.cleaned_data I would 
prefer to use dependency injection in order to get this data and do the job 
done. I'm sorry I just see commit=False as an anti-pattern, because the 
validation needs to be repeated after that (as your example in the first 
post).

Showing an error message which the user cannot correct is a horrible UX 
indeed, but still its a UX, and some people may find it as a better 
alternative to a `500 server error page`, where there is no UX at all. Even 
a generic message like 'sorry we messed up' would be useful, because the 
user data that will be preserved into the form. However, in the example 
shown here, this is not even the case, there is something that the user can 
do to prevent the error.

Finally, yes, there may never be a 100% guarantee that an instance can 
actually be saved, but this would be outside of Django's scope? In terms of 
a model.save() things are deterministic and we should do doing our best to 
ensure that the operation is valid for execution, right? In the example I'm 
showing is not something outside of Django's knowledge to make it 
unexpected/unpreventable.

Thank you,
Todor.


On Sunday, October 8, 2017 at 7:36:58 PM UTC+3, Florian Apolloner wrote:
>
>
>
> On Saturday, October 7, 2017 at 5:07:31 PM UTC+2, Todor Velichkov wrote:
>>
>> I believe this could save a lot of headache to people. If there is no 
>> guarantee that an instance cannot be saved after the form has been 
>> validated, then do not give me an option to shoot myself into the foot.
>>
>
> Even if the whole instance were validated there is __never__ and can 
> __never__ be any guarantee that the instance can actually be saved.
>
>
>> My only concern here actually is not that we didn't know what will happen 
>> (I think we know that), but how to show the user that the developer got 
>> messed up, i.e. how to render an error for a field that is not rendered to 
>> the user? Should this error be propagated to a NON-FIELD error or something 
>> else?
>>
>
> Showing an error message which the user cannot correct because the field 
> is not in the form is horrible UX.
>
> I feel its perfectly fine to ask for a complete model instance at this 
>> stage of the validation process (lots of methods got passed from the 
>> beginning - form.clean() and instance.clean()).
>>
>
> I strongly disagree, especially for values which are set programmatically 
> after validation (with the use of save(commit=False)) depending on values 
> the user chose. Ie when the user chooses a category for a bug report and 
> the code then automatically assigns another user as owner of that 
> reuqest/ticket.
>
> Cheers,
> Florian
>

-- 
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/61db7623-a32b-4d1d-890d-f1ce463d8c91%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.