Function get_serialized_data has 5 arguments (exceeds 4 allowed). Consider refactoring.

Eu acredito que nesse caso, as mensagens de erro devem ser mais descritivas.
Ao realizar uma pesquisa, tive certa dificuldade em saber o que estava fazendo de errado.

Olá, modificarei as mensagens para torná-las mais descritivas.

Não entendi o propósito dessas linhas de código. Poderia elaborar um pouco sobre?

Olá, Caio! O propósito deste trecho de código é filtrar as disciplinas que por ventura tenham sido encontradas pelo nome, porém devido ao critério de horário, não possua nenhuma turma associada. Isso pode ocorrer caso o estudante pesquise por exemplo:

• Cálculo 1
• 234N23
  e não exista nenhuma turma com esse horário. A ideia seria não retornar o objeto de Disciplines com a lista de classes vazia, pois pode comprometer a experiência do usuário.

Caso a pesquisa acima fosse modificada para

• Calc
• 234N23
  existe a possibilidade de outras matérias possuírem turmas neste horário e, caso a matéria de Cálculo 1 não fosse removida do data, o usuário iria receber uma lista de disciplinas onde uma delas não possui turmas.

Entendi. Essa abordagem não é muito performática por conta das frequentes buscas lineares para remoção, e também das remoções (que será linear).

Acho que seria melhor algo desse tipo:

data = list(filter(lambda value: len(value) > 0, data))

O search_by_schedule = True aparece duas vezes. Acho que poderia remover esses trechos do escopo local das estruturas de condição e adicionar o atributo da variável apenas uma vez em um escopo mais geral. O que acha?

Não entendi muito bem o uso do filter_disciplines_by_schedule_and_department_code em conjunto com o filter_classes_by_schedule. Esse Q(classes__schedule__icontains=schedule) não filtra as aulas através do código? Logo em seguida, é utilizada a outra função. Algum dos dois são inutilizados, não?

Olá, Caio! A função filter_disciplines_by_schedule_and_department_code() serve para encontrar disciplinas que possuam alguma turma com o horário especificado. Uma vez feito isso, antes de retornar a disciplina para o front-end, é necessário filtrar, dentre as turmas do objeto Discipline em questão, as turmas que coincidem com o horário especificado.

Algo parecido é feito na busca por professor, uma vez que encontramos disciplinas com turmas com o professor especificado, nós filtramos, dentre as turmas daquela disciplina, somente as turmas daquele professor.

Essa filtragem de turmas é feita dentro serializer após obter os objetos disciplines em questão.

class DisciplineSerializer(DisciplineSerializerSchedule):
    classes = serializers.SerializerMethodField()

    def get_classes(self, discipline: Discipline):
        teacher_name = self.context.get('teacher_name')
        schedule = self.context.get('schedule')
        classes = discipline.classes.all() if hasattr(
            discipline, 'classes') else Class.objects.none()
        if teacher_name:
            classes = dbh.filter_classes_by_teacher(
                name=teacher_name, classes=classes)
        if schedule:
            classes = dbh.filter_classes_by_schedule(
                schedule=schedule, classes=classes)
        return ClassSerializer(classes, many=True).data

Não conheço uma maneira de filtrar os objetos classes relacionados ao objeto discipline diretamente na filtragem de objetos Discipline utilizando o ORM padrão do Djano. Talvez seja interessante utilizar uma query em SQL que já realize a filtragem completa.

O que acha?

Algo parecido é feito na busca por professor, uma vez que encontramos disciplinas com turmas com o professor especificado, nós filtramos, dentre as turmas daquela disciplina, somente as turmas daquele professor.

Entendi. Se já temos um sistema dessa forma, vamos manter então (pelo menos por enquanto).
Nunca tinha reparado, não me parece ser tão interessante seguir dessa maneira. Não estamos verificando esses atributos duas vezes?

Talvez seja interessante utilizar uma query em SQL que já realize a filtragem completa.

O que acha?

Por enquanto, vamos manter do jeito em que está mesmo. Para utilizar uma query em SQL, temos que verificar as opções que o framework entrega pra gente (se é anti SQL Injection e tudo mais).

Para essa thread, só basta a resolução do problema reportado que é o mesmo do filter_classes_by_schedule. Valeu!

A proposta por realizar um filtro através do horário é boa, mas acho que não é eficiente utilizando essa função. Pelo o que eu entendi, ela vai encontrar padrões que contém trechos diretos. Por exemplo:

Imagine que temos uma lista de matérias distintas, com os seguintes horários:

schedules = ['24M34', '46M34']

Se eu realizo uma query para receber matérias que possuem o horário 4M34, receberei apenas a primeira matéria, sendo que a segunda também possui o mesmo padrão.

Essa pesquisa é funcional, mas se limita a uma substring de horário.

EDIT: A função icontains é equivalente:

SELECT classes WHERE schedule ILIKE '%4M34%';

Se a query fosse desse tipo (abaixo), o problema seria resolvido:

SELECT classes WHERE schedule ILIKE '%4%M%3%4%';

Ou seja: Com a query 4M34, pode ter qualquer coisa antes do primeiro 4 e depois também. Logo após isso, vem o M e também pode ter qualquer coisa entre o 3 e 4.

Excelente observação, Caio! Concordo com as sugestões e irei modificar o código para implementá-las.

Não utilizamos esse padrão de separação de decorators.