Subscribe: Django: Timeline
http://code.djangoproject.com/timeline?daysback=90&max=50&wiki=on&ticket=on&changeset=on&milestone=on&format=rss
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
created  django contrib  django  file home  file  fixed fixed  fixed  home portal  lib python  test  ticket  venv lib 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Django: Timeline

Django



Trac Timeline



 



Ticket #29040 (test database creation log output doesn't use consistent stream) created

Fri, 19 Jan 2018 18:38:57 GMT

While troubleshooting a test issue, I ran into confusing output that I tracked down to `base/creation.py` (code shown below) logging its log output to two different streams. This caused messages to display different from their actual order.

Specifically, I was seeing the following message:

Got an error creating the test database: ...

after this message:

Destroying old test database for alias 'default'

when the actual order is the reverse:

sys.stderr.write(
    "Got an error creating the test database: %s\n" % e)
if not autoclobber:
    confirm = input(
        "Type 'yes' if you would like to try deleting the test "
        "database '%s', or 'no' to cancel: " % test_database_name)
if autoclobber or confirm == 'yes':
    try:
        if verbosity >= 1:
            print("Destroying old test database for alias %s..." % (
                self._get_database_display_str(verbosity, test_database_name),
            ))
        cursor.execute('DROP DATABASE %(dbname)s' % test_db_params)
        self._execute_create_test_db(cursor, test_db_params, keepdb)
    except Exception as e:
        sys.stderr.write(
            "Got an error recreating the test database: %s\n" % e)
        sys.exit(2)

I think the correct solution is for this module to be logging all output to stderr (e.g. like Python's default logging behavior) -- reserving stdout for structured / API output. But even just outputting all messages to the same stream would be a big improvement.

I also think it would be a good idea to define a function like log() instead of having print() and sys.stderr.write() occur throughout. That would allow logging code to be controlled more centrally (aka DRY).




Ticket #29039 (Disabling migrations doesn't work with --keepdb) created

Fri, 19 Jan 2018 12:58:41 GMT

We have a large number of migrations in our application now, and as a result it can take 20 mins to create a test DB.
To make this faster I am settings MIGRATION_MODULES in my settings as follows:

MIGRATION_MODULES = {}
for app in INSTALLED_APPS:
    if app.startswith('django.contrib.'):
        app=app.replace('django.contrib.', '')
    MIGRATION_MODULES[app] = None

I've found that this breaks the --keepdb option as it Django wants to run sync_db internally every time.

The workaround I found is to modify django.db.backends.creation.py (lines 64 to 70) from

    call_command(
            'migrate',
            verbosity=max(verbosity - 1, 0),
            interactive=False,
            database=self.connection.alias,
            run_syncdb=true,
        )

To

    call_command(
            'migrate',
            verbosity=max(verbosity - 1, 0),
            interactive=False,
            database=self.connection.alias,
            run_syncdb=not keepdb,
        )



Changeset [649d5ea]: [1.11.x] Fixed #29032 -- Fixed an example of using expressions in ...

Fri, 19 Jan 2018 07:58:46 GMT

[1.11.x] Fixed #29032 -- Fixed an example of using expressions in QuerySet.values().

Backport of 7fbb1bd00d8a3e9a834de83d36ebcbff15c18938 from master




Changeset [c881c4f1]: [2.0.x] Fixed #29032 -- Fixed an example of using expressions in ...

Fri, 19 Jan 2018 07:57:28 GMT

[2.0.x] Fixed #29032 -- Fixed an example of using expressions in QuerySet.values().

Backport of 7fbb1bd00d8a3e9a834de83d36ebcbff15c18938 from master




Ticket #29032 (Docs example for expressions in QuerySet.values() doesn't work) closed

Fri, 19 Jan 2018 07:56:01 GMT

fixed:

In 7fbb1bd0:

Fixed #29032 -- Fixed an example of using expressions in QuerySet.values().




Changeset [7fbb1bd0]: Fixed #29032 -- Fixed an example of using expressions in ...

Fri, 19 Jan 2018 07:55:29 GMT

Fixed #29032 -- Fixed an example of using expressions in QuerySet.values().




Ticket #29038 (Render HTML void elements without a solidus) created

Fri, 19 Jan 2018 05:04:42 GMT

In HTML5 syntax, the solidus for void elements is optional and has no effect.

As Django already uses HTML5 specific syntax (e.g. boolean attributes), can take advantage of other HTML5 syntax. Therefore, can render HTML tags without a final solidus.

The HTML5 spec says:

if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS character (/). This character has no effect on void elements




Ticket #29037 (Add a bulk_update method to models) created

Fri, 19 Jan 2018 00:23:45 GMT

Currently it's not easily or neatly possible to update multiple rows with differing values using the ORM. Most people who need to update a number of models with a value that's distinct to each model need to issue N queries. This is akin to the situation that lead to the addition of bulk_create.

Updating multiple rows with differing values in a single query is indeed possible in SQL, and Postgres has some specific syntax for it[1]. Other databases can use a CASE/WHEN:

SomeModel.object.filter(id__in=[1,2]).update(
    some_field=Case(
        When(id=1, then=Value('Field value for ID=1')),
        When(id=2, then=Value('Field value for ID=2'))
    )
)

This isn't particularly elegant and cannot take advantage of specific DB features (like pg UPDATE FROM), and batching is hard. An API similar to bulk_create would be nice:

SomeModel.objects.bulk_update(list_of_models, batch_size=100, fields=['some_field'])

There is some prior art in the django-bulk-update package[2], which has some impressive performance numbers in it's readme.

  1. https://stackoverflow.com/questions/18797608/update-multiple-rows-in-same-query-using-postgresql
  1. https://github.com/aykut/django-bulk-update



Changeset [afd50a3]: Replaced "trunk" with "master branch" in docs.

Thu, 18 Jan 2018 21:30:38 GMT

Replaced "trunk" with "master branch" in docs.




Changeset [90ca941]: Removed unnecessary microsecond truncation in SplitDateTimeWidget. ...

Thu, 18 Jan 2018 16:23:06 GMT

Removed unnecessary microsecond truncation in SplitDateTimeWidget.

The microseconds are already truncated by the TimeInput subwidget.




Changeset [3c34452a]: Refs #23668 -- Removed passing default argument of current TZ to ...

Thu, 18 Jan 2018 16:21:12 GMT

Refs #23668 -- Removed passing default argument of current TZ to make_aware()/naive.




Ticket #29036 (HTML5 required validation does not work for SelectDateWidget) created

Thu, 18 Jan 2018 14:04:57 GMT

SelectDateWidget uses 0 as a empty value. When the field uses HTML5 required attribute to make browser check the input, it does not work. Browsers (tested with Firefox 52.5 and Chromium 62) consider selected 0 as filled, thus required check incorrectly passes.

I suggest to use empty string as a value for SelectDateWidget.none_value.




Ticket #29035 (Django Admin does not URL encode the search terms of list filters, ...) created

Thu, 18 Jan 2018 04:20:50 GMT

I have a model with a float field which I included in the ModelAdmin under list_filter.

The float values of the model field are displayed as list filter links in the Django admin, but the period in the float value is not URL encoded, so the request fails and reverts to an unfiltered list.




Ticket #29034 (App Configs do not correctly handle static files) closed

Thu, 18 Jan 2018 03:51:29 GMT

worksforme:

I can't reproduce a problem and if there were a bug, I think we'd have heard about it before now. You can seek help on our support channels. If you provide an upload of your project, someone may be able to debug it and find where you went wrong.




Changeset [65728550]: Refs #28643 -- Added Replace database function.

Thu, 18 Jan 2018 01:46:15 GMT

Refs #28643 -- Added Replace database function.




Ticket #29034 (App Configs do not correctly handle static files) created

Wed, 17 Jan 2018 23:09:51 GMT

When following along with the djagno Polls tutorial I noticed the following behavior:

In tutorial 6 we learn about static files, and about how to correctly include them in our polls app. Following along with the tutorial exactly however leads us to a situation where the static files are not correctly included in the application and therefore our style.css does not get imported to our application.

The issue lies in tutorial 2 - where we first included our polls app in settings.py via INSTALLED_APPS:

INSTALLED_APPS = [
    'polls.apps.PollsConfig',
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

Using this method, static files do not get correctly imported to the app for inclusion in templates/etc

To fix this in the polls application, modifying INSTALLED_APPS as below produces the expected behavior (static files get included and can be accessed via templates.

INSTALLED_APPS = [
    'polls',
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

According to apollo13 this seems to be a bug with handling of static files with app configs.

A quick fix for the tutorials may be changing the include text to just be "polls" vs "polls.apps.PollsConfig" however this may not be the desired syntax for app config includes.




Ticket #29033 (Sitemap framework does not properly detect secure requests) created

Wed, 17 Jan 2018 21:27:12 GMT

Django settings provides the option of overriding the detected protocol by setting SECURE_PROXY_SSL_HEADER, however contrib.sitemaps just defaults to 'http' if the protocol in the Sitemap class is not overridden.

Ideally contrib.sitemaps would use the request.is_secure() method to detect the protocol in the request and default to that instead.

I would be happy to provide a patch but I feel some discussion is required. The sitemap.xml views are easily fixed, however complexity is added when updating the defaults in get_urls on the Sitemap object as it doesn't have access to the request object.




Ticket #29032 (Docs example for expressions in QuerySet.values() doesn't work) created

Wed, 17 Jan 2018 18:53:57 GMT

The Blog.objects.values('author', entries=Count('entry')) example added in 39f35d4b9de223b72c67bb1d12e65669b4e1355b crashes with FieldError: Cannot resolve keyword 'author' into field..

(reported django-users)




Ticket #16484 (Duplicate entry sessions error) closed

Wed, 17 Jan 2018 18:32:21 GMT

duplicate:

Providing only a traceback does not help much (also none of the previous discussion references PostgreSQL, so reopening doesn't seem appropriate). Please open a new ticket with complete details to reproduce the issue and make sure you can reproduce it with the latest version of Django rather than 1.8.




Ticket #29014 (State that sqlite >= 3.7.15 is supported) closed

Wed, 17 Jan 2018 17:15:58 GMT

wontfix:

This is inconsistency and theoretical concern.




Changeset [fcd431c6]: Improved generic detail view error message for when pk or slug is missing.

Wed, 17 Jan 2018 15:58:05 GMT

Improved generic detail view error message for when pk or slug is missing.




Ticket #28857 (Cast function may generate invalid SQL on PostgreSQL for complex ...) closed

Wed, 17 Jan 2018 15:02:31 GMT

fixed:

In 27557a7a:

Fixed #28857 -- Fixed invalid SQL when using Cast with complex expressions on PostgreSQL.




Changeset [27557a7a]: Fixed #28857 -- Fixed invalid SQL when using Cast with complex ...

Wed, 17 Jan 2018 14:28:03 GMT

Fixed #28857 -- Fixed invalid SQL when using Cast with complex expressions on PostgreSQL.




Changeset [b902878f]: Doc'd the latest state of the Jenkins pull request builders.

Wed, 17 Jan 2018 13:48:53 GMT

Doc'd the latest state of the Jenkins pull request builders.




Ticket #29014 (State that sqlite >= 3.7.15 is supported) closed

Wed, 17 Jan 2018 13:39:36 GMT

needsinfo



Ticket #29025 (Security middleware for insecure (HTTP) connections) closed

Wed, 17 Jan 2018 13:14:38 GMT

wontfix:

The django-developers discussion hasn't yielded a consensus to incorporate this into Django.







Changeset [de1520e]: [1.11.x] Fixed typo in docs/topics/i18n/translation.txt. Backport of ...

Wed, 17 Jan 2018 07:54:20 GMT

[1.11.x] Fixed typo in docs/topics/i18n/translation.txt.

Backport of 196c257a230bba8f2f1b2021c383eb2744e8df41 from master




Changeset [fbe7c8f]: [2.0.x] Fixed typo in docs/topics/i18n/translation.txt. Backport of ...

Wed, 17 Jan 2018 07:50:26 GMT

[2.0.x] Fixed typo in docs/topics/i18n/translation.txt.

Backport of 196c257a230bba8f2f1b2021c383eb2744e8df41 from master




Changeset [196c257a]: Fixed typo in docs/topics/i18n/translation.txt.

Wed, 17 Jan 2018 07:47:37 GMT

Fixed typo in docs/topics/i18n/translation.txt.







Ticket #29031 (@permission_required decorator not Working) created

Wed, 17 Jan 2018 02:26:59 GMT

User does not have the delete permission but can delete record by ajax delete request with method 'POST', and the requested function in view has @permission_required decorator required permission of deletion, however it seems does not work any more. The permission_required returns False by debugging the if user has delete permission but it is not working.




Ticket #29029 (Django 1.8.18 admin uses jquery version with security issues) closed

Tue, 16 Jan 2018 22:31:47 GMT

wontfix:

As far as I saw, the admin doesn't use any of the features of jQuery which are vulnerable. If you found differently, please contact security@….




Ticket #29030 (contrib.sites incorrectly documents its use in django.contrib.admin ...) created

Tue, 16 Jan 2018 20:17:38 GMT

The How Django Uses the Sites Framework documentation states the following:

In the admin framework, the “view on site” link uses the current Site to work out the domain for the site that it will redirect to.

This statement seems to be false. In the admin site docs, it states the following:

The URL for the “View site” link at the top of each admin page. By default, site_url is /. Set it to None to remove the link.
For sites running on a subpath, the each_context() method checks if the current request has request.META['SCRIPT_NAME'] set and uses that value if site_url isn’t set to something other than /.

This seems to be backed up by what I am actually seeing, and what the code says that it is doing. Changing the current site's domain in the sites framework has no effect on this link. I suggest removing the incorrect information from the sites documentation. The alternative would be to add this functionality to the admin site.







Ticket #29028 (Warning show up even use `django.utils.timezone.now`) created

Tue, 16 Jan 2018 14:57:56 GMT

Create a new project like usual and create a model like this

from django.db import models
from django.utils import timezone
class Learn(models.Model):
    title = models.CharField(max_length=50)
    pay_time = models.DateTimeField(default=timezone.now())

after running migrations and run server, warning still show up
learn.Learn.pay_time: (fields.W161) Fixed default value provided.

HINT: It seems you set a fixed date / time / datetime value as default for this field. This may not be what you want. If you want to have the current date as default, use django.utils.timezone.now

This model already use django.utils.timezone.now, so I think we should not show this warning.

code on https://github.com/django/django/blob/d7b2aa24f75434c2ce50100cfef3586071e0747a/django/db/models/fields/__init__.py#L1187




Ticket #29027 (file_move_safe error with SELinux) created

Tue, 16 Jan 2018 08:42:34 GMT

PermissionError on upload of large files (large enough to not use the in-memory file class) when SELinux is in enforce mode. The error happens after the file is copied to the destination folder. As seen in the trace below, when copystat is called from file_move_safe, shutil tries to set attributes with setxattr. But this is failing when SELinux is enabled. I noticed on temporarily disabling SELinux that the files which are successfully uploaded now have a context of 'httpd_tmp_t' as opposed to the context of 'httpd_sys_rw_content_t' which the directory is configured with. So, when SELinux is enabled, setxattr is failing when the context of the file is 'httpd_sys_rw_content_t'. Traceback (most recent call last): File "/home/portal/venv/lib/python3.6/site-packages/django/core/handlers/exception.py", line 41, in inner response = get_response(request) File "/home/portal/venv/lib/python3.6/site-packages/django/core/handlers/base.py", line 249, in _legacy_get_response response = self._get_response(request) File "/home/portal/venv/lib/python3.6/site-packages/django/core/handlers/base.py", line 187, in _get_response response = self.process_exception_by_middleware(e, request) File "/home/portal/venv/lib/python3.6/site-packages/django/core/handlers/base.py", line 185, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/home/portal/venv/lib/python3.6/site-packages/django/contrib/auth/decorators.py", line 23, in _wrapped_view return view_func(request, *args, **kwargs) File "/home/portal/project/assignments/views/views.py", line 270, in edit_answer instance.answerfile_set.create(file=upload, file_type=file) File "/home/portal/venv/lib/python3.6/site-packages/django/db/models/fields/related_descriptors.py", line 653, in create return super(RelatedManager, self.db_manager(db)).create(**kwargs) File "/home/portal/venv/lib/python3.6/site-packages/django/db/models/manager.py", line 85, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) File "/home/portal/venv/lib/python3.6/site-packages/django/db/models/query.py", line 394, in create obj.save(force_insert=True, using=self.db) File "/home/portal/venv/lib/python3.6/site-packages/django/db/models/base.py", line 808, in save force_update=force_update, update_fields=update_fields) File "/home/portal/venv/lib/python3.6/site-packages/django/db/models/base.py", line 838, in save_base updated = self._save_table(raw, cls, force_insert, force_update, using, update_fields) File "/home/portal/venv/lib/python3.6/site-packages/django/db/models/base.py", line 924, in _save_table result = self._do_insert(cls._base_manager, using, fields, update_pk, raw) File "/home/portal/venv/lib/python3.6/site-packages/django/db/models/base.py", line 963, in _do_insert using=using, raw=raw) File "/home/portal/venv/lib/python3.6/site-packages/django/db/models/manager.py", line 85, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) File "/home/portal/venv/lib/python3.6/si[...]



Ticket #29026 (Make makemigrations scriptable / script-friendly) created

Tue, 16 Jan 2018 04:57:18 GMT

Currently, the makemigrations management command doesn't lend itself well to scripting. For example, it writes its progress output to stdout rather than stderr. Also, there doesn't appear to be a structured / programmatic way to figure out what files it has created.

My use case is that in my development environment, I'd like to be able to run makemigrations in a Docker container, find out what files were added (e.g. from makemigrations's output), and then copy those files from the Docker container to my development machine so they can be added to source control.

Currently, there doesn't seem to be an easy way to do this. One way, for example, is to manually read makemigrations's output to find out what apps were affected, and then inspect the directories yourself for the new files.

Better, for example, would be if makemigrations could write the paths to the created files to stdout.




Ticket #29025 (Security middleware for insecure (HTTP) connections) created

Mon, 15 Jan 2018 19:50:14 GMT

Hello everyone,

I am starting my contribution to Django and I would like to propose a security middleware that can provide some layer of security even in HTTP connections by encrypting the request and response.

Here I will implement an SSL type feature in the backend and will also provide a corresponding frontend implementation that can be used to complete the encryption-decryption couple.

Please share your thoughts and valuable suggestions, I will appreciate any type of help I can get from you.

P.S. This is just a brief intro about the feature, if you like this and feels something achievable then we can discuss it in detail.

Regards
Vishwas




Ticket #29024 (`TestContextDecorator` never exits if `setUp` fails in tests) created

Mon, 15 Jan 2018 18:22:39 GMT

when using TestContextDecorator as a class decorator, enable is called just before Test.setUp, and disable is called after Test.tearDown. unfortunately, tearDown is not called in the event of a failure inside setUp. This can result in unexpected behaviour. Even though this class is not documented, there are decorators that use it that are. example: class example_decorator(TestContextDecorator): some_var = False def enable(self): self.__class__.some_var = True def disable(self): self.__class__.some_var = False class Example1TestCase(TestCase): def test_var_is_false(self): # some_var will be False self.assertFalse(example_decorator.some_var) @example_decorator() class Example2TestCase(TestCase): def setUp(self): raise Exception def test_var_is_true(self): # won't be hit due to exception in setUp self.assertTrue(example_decorator.some_var) class Example3TestCase(TestCase): def test_var_is_false(self): # some_var will be True now due to no cleanup in Example2TestCase self.assertFalse(example_decorator.some_var) output: .EF ====================================================================== ERROR: test_var_is_true (example.tests.Example2TestCase) ---------------------------------------------------------------------- ... Traceback ====================================================================== FAIL: test_var_is_false (example.tests.Example3TestCase) ---------------------------------------------------------------------- ... AssertionError: True is not false Ran 3 tests in 0.007s FAILED (failures=1, errors=1) There are 2 potential fixes here: decorate setUpClass and tearDownClass use addCleanup inside the setUp decorator addCleanup will always run, and will only ever be registered if the context manager was successfully enabled. It would also be useful to have this class documented, however that's out of scope of this ticket. [...]



Changeset [999fc06]: Added a few tests for smtp EmailBackend.

Mon, 15 Jan 2018 17:25:17 GMT

Added a few tests for smtp EmailBackend.




Changeset [59b1aaa5]: Added a couple tests for collectstatic.

Mon, 15 Jan 2018 16:15:14 GMT

Added a couple tests for collectstatic.




Ticket #28881 (Document that CommonPasswordValidator assumes all words are lower case) closed

Mon, 15 Jan 2018 15:37:02 GMT

fixed:

In 4fcd28d:

Fixed #28881 -- Doc'd that CommonPasswordValidator's password list must be lowercase.




Changeset [146317b7]: [2.0.x] Fixed #28881 -- Doc'd that CommonPasswordValidator's password ...

Mon, 15 Jan 2018 15:36:31 GMT

[2.0.x] Fixed #28881 -- Doc'd that CommonPasswordValidator's password list must be lowercase.

Backport of 4fcd28d442c2fec56f544f99cb658f33f847824c from master




Changeset [4fcd28d]: Fixed #28881 -- Doc'd that CommonPasswordValidator's password list ...

Mon, 15 Jan 2018 15:16:27 GMT

Fixed #28881 -- Doc'd that CommonPasswordValidator's password list must be lowercase.




Ticket #29023 (running tests in parallel doesn't show exception chain, even with tblib) created

Mon, 15 Jan 2018 11:08:39 GMT

Running tests in parallel doesn't show more than the first link of an exception chain. For example, with the following test (with tblib installed):

def test(self):
    time.sleep(2)
    try:
        raise ValueError('foo')
    except Exception:
        raise KeyError('bar')

this is what the failure looks like when running tests in parallel:

Traceback (most recent call last):
  File "/Users/.../versions/3.6.4/lib/python3.6/unittest/case.py", line 59, in testPartExecutor
    yield
  File "/Users/.../versions/3.6.4/lib/python3.6/unittest/case.py", line 605, in run
    testMethod()
  File "/Users/.../myproject/myproject/tests/test_a.py", line 13, in test2
    raise KeyError('bar')
KeyError: 'bar'

In contrast, this is what it looks like when running them not in parallel:

Traceback (most recent call last):
  File "/Users/.../myproject/myproject/tests/test_a.py", line 11, in test2
    raise ValueError('foo')
ValueError: foo
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/Users/.../myproject/myproject/tests/test_a.py", line 13, in test2
    raise KeyError('bar')
KeyError: 'bar'

Side question: why must pickling be used at all? Why can't we simply render the traceback to a string using Python's traceback module, and then send the string back? It seems like that would result in simpler, more understandable code and sidestep many of the difficulties.

(This was reported using Python 3.6.4. and master as of Jan. 15, 2018: 02365d3f38a64a5c2f3e932f23925a381d5bb151 .)




Ticket #29022 (HashedFilesMixin does not properly skip protocol-relative urls) created

Sun, 14 Jan 2018 05:29:32 GMT

While protocol-relative urls have been deprecated it would be nice for Django staticfiles to support it since a lot of code still uses it or explicitly not support it. Right now the relevant snippet implies that the code does filter out protocol-relative urls but it currently does not:

# django/contrib/staticfiles/storage.py
# Ignore absolute/protocol-relative and data-uri URLs.
if re.match(r'^[a-z]+:', url):
    return matched

I've included an example snippet that uses a protocol-relative url but is not filtered:

 @import url("//fonts.googleapis.com/css?family=Source+Sans+Pro:400,700|Raleway:400,800,900");



Ticket #28542 (migration that introduces uuid field is not reversible with unique=True) closed

Sun, 14 Jan 2018 01:37:02 GMT

fixed:

In 02365d3:

Fixed #28542 -- Fixed deletion of primary key constraint if the new field is unique.




Changeset [02365d3]: Fixed #28542 -- Fixed deletion of primary key constraint if the new ...

Sun, 14 Jan 2018 01:11:55 GMT

Fixed #28542 -- Fixed deletion of primary key constraint if the new field is unique.




Ticket #29021 (Weird behavior of foreign key lookup and annotate F expression) closed

Sat, 13 Jan 2018 22:57:56 GMT

needsinfo:

Are you actually seeing this in Django 1.10 as per the ticket field? If so please try to test it on a newer version, e.g. 1.11 or even better 2.0. For two reasons: Django 1.10 support period has finished (https://www.djangoproject.com/weblog/2015/jun/25/roadmap/) and it could be this is a problem which is already solved.

What database backend are you using? Please reopen when you can provide this information.