Django-tables2: 열 머리글로 정렬한 후 중복된 테이블 행

list()를 통해 쿼리 세트를 결정화하면 문제가 발생하지 않습니다.

+++ b/django_tables2/rows.py
@@ -8,6 +8,7 @@ from django.utils import six
 from .columns.linkcolumn import BaseLinkColumn
 from .utils import A, AttributeDict, call_with_appropriate, computed_values

+import sys

 class BoundRow(object):
     """
@@ -187,9 +193,26 @@ class BoundRows(object):
     def __init__(self, data, table):
         self.data = data
         self.table = table


     def __iter__(self):
+        print >>sys.stderr, type(list(self.data.data))

보고해 주셔서 감사합니다. 목록으로 캐스팅하는 것은 더 큰 데이터 세트에서는 작동하지 않으므로 솔루션으로 허용되지 않습니다.

Django 버전 업데이트에 문제가 없는지 확인하기 위해 django-tables2 버전을 다운그레이드할 수 있습니까?

예, 확실히 해결책은 아니지만 원인을 나타낼 수 있습니다. 목록으로 캐스팅하는 것이 적절한 솔루션이 아닌 다른 이유는 그것이 항상 데이터를 보유하는 쿼리 세트인 것처럼 보이지 않기 때문입니다. 이 경우에는 self.data.data가 존재하지 않습니다.

@wtfrank ,

나는 같은 문제에 직면하고 있다고 생각합니다. 내 테이블에서 하나의 행이 누락되었고 다른 하나는 중복되었습니다... 저에게 이것은 버전 1.2.2부터 시작되었습니다.
1.2.1 "fixxes"로 다운그레이드하면 문제가 해결됩니다. 검색을 더 쉽게 하기 위해 제공할 수 있는 정보가 있습니까?

최소한의 테스트 케이스가 있으면 정말 좋을 것입니다. 그런 다음 git bisect를 실행하여 잘못된 커밋을 찾을 수 있습니다.

현재 테스트 케이스를 조사하고 있지만 이상하게도 테스트 환경에서 문제를 재현할 수 없습니다...

로컬(sqlite를 사용하여 ./manage runserver 사용)은 모두 문제가 없지만 프로덕션(uwsgi 및 mysql 실행)에서는 속임수 문제가 존재합니다...(두 환경 모두 동일한 버전에서 실행됨)

쿼리 세트에는 속임수가 포함되어 있지 않습니다.... 그러나 table.html이 렌더링될 때 쿼리 세트에는 하나의 개체가 누락되고 다른 하나는 중복됩니다...

곧 테스트 케이스로 다시 돌아오겠습니다 :)

이 문제는 1.2.6 버전에서도 발생합니다. # 329 또는 # 330으로 sth라고 생각하지만 지금까지 고칠 방법을 찾지 못했습니다.

그것들은 1.2.6에만 적용 가능하기 때문에 이 버그의 원인이 될 것이라고는 생각하지 않습니다.

죄송합니다. 재현 가능한 적절한 사례를 제공할 수 없지만 방금 이 문제가 발생했으며(또는 적어도 이 문제라고 생각합니다) 1.2.1과 1.2.2 사이에 확실히 발생했음을 알 수 있습니다. .

1.2.1로 다운그레이드할 때마다 모든 것이 괜찮아 보입니다. 1.2.2 이상으로 업그레이드할 때(물론 최신 1.2.6으로 시작했습니다), 일관되게 첫 번째 행(DB에 있는 3개 중)을 잃고 그 대신 다른 행의 사본을 얻습니다. 예를 들어, 1.2.1에 있을 때:

| 날짜 | 히트 | ... |
| --- | --- | --- |
| 2016-10-08 | 123 | ... |
| 2016-10-07 | 321 | ... |
| 2016-10-06 | 0 | ... |

1.2.2-1.2.6에서 나는 일관되게 이것을 대신 얻습니다.

| 날짜 | 히트 | ... |
| --- | --- | --- |
| 2016-10-06 | 0 | ... |
| 2016-10-07 | 321 | ... |
| 2016-10-06 | 0 | ... |

저는 Python 2.7.12에서 Django 1.9.9를 사용하고 있으며 프로젝트는 pydanny/cookiecutter-django를 사용하여 시작되었으며(그 이후에 크게 수정되었지만) 내 코드는 다음과 같습니다.

class DailySummaryTable(tables.Table):
    class Meta:
        model = DailySummary
        attrs = {"class": "paleblue"}
        empty_text = _("No stats yet")
        fields = ("date", "hits", ...long boring list...)
        # order_by = ("-date",)
        # orderable = False

모델의 Meta 에는 verbose_name{,_plural} 있고 보기는 다음과 같은 간단한 DetailView 입니다.

class SourceDetailView(LoginRequiredMixin, DetailView):
    model = Source
    ...
    def get_context_data(self, **kwargs):
        ctx = super(...)
        ctx["stats"] = DailySummaryTable(DailySummary.objects.filter(source=self.object))
        return ctx

그리고 DB(PostgreSQL 9.6)에는 모두 동일한 source_id (하나만 있음)를 갖는 3개의 행이 있으므로 모두 쿼리와 일치합니다. 이상하게도 .filter(source=...) 를 .all() 로 바꾸면 문제가 사라지는 것 같습니다.

그게 내가 알아낼 수 있는 전부였다. 도움이 되기를 바랍니다. 나는 지금 1.2.1을 고수할 것 같다. :)

방황하는 모습을 보여주셔서 감사합니다. 나중에 이 문제를 살펴보겠습니다.

방금 같은 문제에 부딪쳤습니다. list()를 통해 쿼리 세트를 결정화하는 것은 우리 측에서도 실행 가능한 솔루션이 아닙니다.

@op-alex-reid는 사용 사례를 최소한의 재현 가능한 테스트 사례로 전환할 수 있습니까?

다음 코드에 동일한 문제(Django==1.9, django-tables==1.2.3)가 있습니다.

class UserPlayerTable(tables.Table):
    actions = tables.LinkColumn('player:my_players_detail', args=[A('slug')],
                                text=_('View / Edit'),
                                verbose_name=_('View / Edit'), empty_values=())
    embed = tables.LinkColumn('player:my_players_embed', args=[A('slug')],
                                text=_('View / Embed now'),
                                verbose_name=_('View / Embed now'), empty_values=())

    class Meta:
        template = 'tables/table.html'
        model = Player
        fields = ('created', 'slug', 'actions', 'embed')
        attrs = {"class": "changeset"}
        order_by = ['-created']
        orderable = False

그리고

UserPlayerTable(Player.objects.filter(user=context['impersonate_user']))

흥미롭게도 orderable = True 설정하면 문제가 발생하지 않습니다.

제 경우에는 list() 를 통해 쿼리 세트를 결정화하는 것은 _is_ 옵션(지금은 수정 사항)입니다. 테이블에 최대 5개의 행만 있기 때문입니다.

예를 들어 주셔서 감사합니다!

이 코드를 사용하여 이것을 재현해 보았습니다.

class Player(models.Model):
    person = models.ForeignKey(Person)
    created = models.DateTimeField(auto_now_add=True)
    score = models.PositiveIntegerField()

def test_issue_361(per_page=5):

    bob = Person.objects.create(first_name='Bob', last_name='Builder')
    eve = Person.objects.create(first_name='Eve', last_name='Dropper')

    for i in range(10):
        Player.objects.create(person=bob, score=randint(0, 200))
        Player.objects.create(person=eve, score=randint(200, 400))
        Player.objects.create(person=bob, score=5)
        Player.objects.create(person=eve, score=5)

    class UserPlayerTable(tables.Table):
        class Meta:
            model = Player
            fields = ('person.name', 'score',)
            order_by = ['-score']
            orderable = False

    queryset = Player.objects.filter(score=5)

    table = UserPlayerTable(queryset)
    RequestConfig(request, paginate={'per_page': per_page}).configure(table)
    html = table.as_html(request)

    # count the number of rows, subtract one for the header
    assert (html.count('<tr') - 1) == per_page

그러나 이것은 중복 된 행을 생성하지 않습니다 ...

오늘 같은 문제가 발생했습니다. 저는 Django==1.10 프로젝트에서 django-tables2==1.2.9를 사용하고 있습니다. 여기서 django-filters==1.0.1도 사용합니다.

흥미롭게도 내 테이블의 행이 두 배로 늘어나는 것은 다음과 같은 경우에만 발생합니다.

1. 표시할 항목이 많이 있습니다.
   (따라서 페이지당 25개의 레코드로 페이지 매김을 활성화하면 모든 것이 정상이지만 전체 데이터 세트를 표시하면 동일한 항목이 여러 개 나타납니다.)

2. 테이블이 문자열이 아닌 열을 기준으로 정렬됩니다.
   (예를 들어 이름이 포함된 열을 기준으로 정렬하면 모든 것이 좋지만 날짜, int 또는 bool이 있는 열을 기준으로 정렬하면 문제가 발생합니다)

1.2.1로 다운그레이드하면 문제가 해결되지만 실제로는 옵션이 아닙니다.
게다가 {{filter.qs.count}} 카운트가 있어야 하는 대로이기 때문에 속임수는 실제 항목 대신 표시 되고 추가되지 않는 것 같습니다.

django-tables2로 작업하는 것을 즐긴다는 점 외에는 이것이 문제의 핵심을 파악하는 데 조금이나마 도움이 되기를 바랍니다.

모든 작업에 감사드립니다!

@n0ctua 감사합니다!

실행된 정확한 쿼리를 보고 여기에서 공유할 수 있습니까?

저도 방금 이 문제를 겪었고 왜 저에게 이런 일이 일어나는지 이해했습니다. 그래서 다른 사람들도 같은 이유로 문제가 있는 것 같아 게시할 것이라고 생각했습니다. _(하지만, 나는 django-tables2의 다른 버전으로 시도하지 않았기 때문에 이것이 왜 이런 일이 일어나지 않는지 이해하지 못하기 때문에 틀릴 수 있습니다... 비록... 실제로 그것에 대해 생각해보면 나는 이것이 이전 버전에서는 페이지가 매겨지지 않은 테이블이 각 행에 대한 쿼리 대신 DB에 대해 단일 쿼리를 실행했기 때문입니다. 자세한 내용은 아래에서...)_

고유하지 않은 필드에 대한 _SQL order by 결정적이지 않기 때문입니다_. 따라서 top n 결합하면 동일한 상위 n개 행을 계속해서 얻게 됩니다. (또한 어떤 이유로 페이지 매김 없이 Table 를 생성하면 _every_ row. IE top 1 대한 쿼리가 생성됩니다.)

여기에 가장 좋은 솔루션이 무엇인지 잘 모르겠습니다. 이것이 작동하도록 보장하는 유일한 방법은 항상 마지막 order by 가 고유한 필드에 있도록 하는 것입니다. 이상적으로는 기본 키? 또한 이에 대한 경고를 문서에 추가할 가치가 있습니까?

별도의 문제이지만 이러한 일이 발생하는 빈도를 줄이고 페이지가 매기지 않은 테이블에 대한 쿼리 속도를 높이는 문제는 테이블의 모든 행에 대해 top 1 쿼리를 실행하는 대신 단일 쿼리를 실행하는 경우입니다. 모든 결과를 가져오는 쿼리입니다.

@intiocean 페이지가 매겨지지 않은 테이블에 대한 이 쿼리 수는 매우 이상합니다. 왜 이런 일이 발생하는지 확실하지 않으며 발생해서는 안 됩니다. 이 테스트 케이스는 문제를 보여줍니다.

def test_single_query_for_non_paginated_table(settings):
    '''
    A non-paginated table should not generate a query for each row, but only
    one query to count the rows and one to fetch the rows.
    '''
    from django.db import connection
    settings.DEBUG = True

    for i in range(10):
        Person.objects.create(first_name='Bob %d' % randint(0, 200), last_name='Builder')

    num_queries_before = len(connection.queries)

    class PersonTable(tables.Table):
        class Meta:
            model = Person
            fields = ('first_name', 'last_name')

    table = PersonTable(Person.objects.all())
    request = build_request('/')
    RequestConfig(request, paginate=False).configure(table)
    table.as_html(request)

    # print '\n'.join(q['sql'] for q in connection.queries)
    assert len(connection.queries) - num_queries_before == 2

실패한 페이지 매김 사례에 대한 테스트를 만들려고 시도했지만 실패했습니다. 왜 그런지는 모르겠지만 페이지가 매겨진 경우에는 모든 것이 정상적으로 작동하는 것처럼 보입니다... 고유하지 않은 필드를 기준으로 정렬하면 여러 페이지에 복제된 것처럼 보이는 행을 얻을 수 있을 거라고 생각했습니다.

@intiocean 10f5e968bc10552be0ad02ee566513b5d274d5c5로 수정한 것 같아요

@jieter 대단해! 페이지가 매겨지지 않은 테이블의 문제가 해결되는 이유를 알 수 있지만 데이터가 다른 페이지에 분산되어 있을 때 고유하지 않은 열을 기준으로 정렬하면 top n ... limit x offset y 로 인해 동일한 행이 여러 페이지에 나타날 수 있다고 생각합니다.

어떻게 생각하나요?

유사: http://stackoverflow.com/questions/31736700/duplicate-elements-in-django-paginate-after-order-by-call

@wtfrank , @intiocean @n0ctua @op-alex- reid @fliphess 이 문제를 해결할 수 있는 일부 커밋을 마스터에 푸시했습니다. 확인할 수 있습니까?

@intiocean 이것이 이 문제의 원인이라면 이 동작을 문서화함으로써 부분적으로만 이 문제를 해결할 수 있다고 생각합니다.

이것이 페이지 매김되지 않은 테이블 @jieter를 수정한다는 것을 확인할 수 있습니다. 또한 각 행에 대해 쿼리가 하나가 아닌 하나의 쿼리만 있으므로 페이지를 매기지 않은 테이블의 성능도 향상됩니다.

확인하다:
962f502 및 '메모' 열 기준 정렬 -> 중복

f853078을 사용하고 '메모' 열을 기준으로 정렬 -> 중복 없음 🎉

릴리스 @jieter를 할 수 있는 기회가 있습니까?

우와 드디어 고쳐졌다!

네, 1시간 이내에 풀어드리겠습니다.

1.4.0 출시

굉장합니다, 감사합니다 @jieter!

@jieter 와 @intiocean 모두 이 문제 를 해결해 주셔서 감사합니다! 이제 완벽하게 작동합니다.

안녕하세요, 방금 1.21.2 버전 및 Django==2.0.6에서 이 문제를 경험했습니다. intiocean 의 comment 덕분에 'pk'로 추가 순서를 설정하여 수정했습니다.