Après lire le code source d’un projet externe ça demande vraiment d’être expérimenté, faut pas déconner. Souvent on entend des gens dire “lisez les sources ça fait progresser”, mais y a un fossé entre pouvoir jeter un coup d’oeil à un fichier et comprendre toutes les implications dans un projet. Pour ce dernier, il faut avoir codé pas mal de projets soi-même.

Pour ce cas là ça m’a pris une bonne demi-heure à une heure. Je savais déjà ce que je voulais faire car j’avais cherché longtemps un moyen de le faire. Donc j’ai juste regardé le code source du truc qui me le permettait pas, et j’ai tenté de le modifier jusqu’à ce que ça marche dans un test unitaire à l’arrache. La tricherie c’est que DRF utilise pas mal de design patterns que je connais bien, et ça change tout car quand je le vois faire quelque chose, ça me parle. D’autant que j’avais déjà regardé le code source de DRF dans des missions précédents et ce n’était pas une base non familière.

@lollo : DRF marchera très bien pour ça, on peut tout faire sans ORM. Mais vue que tu fais un sous appel à un autre système derrière pour des raisons de perfs tu voudras peut être plutôt taper dans un framework asynchrone. Cherche un micro framework tout simple si c’est le cas. L’avantage de DRF c’est qu’il gère toute l’authentification, et c’est pas rien sur une API. Le désavantage c’est que c’est un gros morceau.

@Pyglouthon : c’est pas faux :)

Je ne fais plus trop de Django depuis un moment mais sur mes projets Flask + marshmallow je définis aussi mon schema (~serializer) avec des champs en dump_only et d’autres en read_only. T’es pas tant que ça une grosse feignasse vu comme tu te fais chier à aller fouiner le code source pour faire ta tambouille. T’es surtout un bon geek curieux, un macgyver du Python web :-)

Faut vraiment que je sois bloqué par les limites du package ou que la doc soit inexistantes pour en arriver là. Bon c’est vrai, ça arrive souvent avec les packages pour flask.

Trop bien cet article.

J’ai un truc a faire depuis des mois et je m’y suis pas encore attelé.. surement car j’ai pas encore la BONNE solution.

J’ai un point API json_rcp assez sale et verbeux auquel je peux pas toucher, car utilisé dans une autre condition.

Je veux donc faire un bridge API json_rpc qui expose des methodes faisant intervenir plusieurs appel json, changeant la structure et filtrant les data.

je me demande quel est le top framework REST pour faire ca.. Car les solutions que j’ai trouvé sont assez dependante de l’ORM

Tu passes simplement ta paume sur la doc à la Matrix ?

Ou tu fais des dessins au crayon, ou tu utilises un UML generator pour visualiser vite fait la tuyauterie ?

quand je regardes des codes sources sur nullege, arrivé en bas du fichier, ma mémoire et déjà saturée depuis 5 minutes… Alors pour trouver un hack , jte racontes pas le fossé.

Combien de temps ça t’a pris à cogiter pour ce cas en particulier ?

Les corrections sont au niveau de la méthode from_serializer et de l’appel dans le serializer.

Dans la méthode from_serializer, pour respecter la méthode type, il faut que le 2ème argument soit un tuple: [cls] -> (cls,)

Comme on passe une classe et non une instance, on ne peut pas faire serializer.class.name mais plutôt serializer.__name__

Enfin au niveau du serializer, on utilise la méthode de classe from_serializer à laquelle on passe la classe du serializer à utiliser, ce qui nous donne une nouvelle classe de laquelle on appelle le constructeur:

bar = AsymetricRelatedField.from_serializer(BarSerializer)()

En tout cas, ce que je n’avais pas mis dans mon premier post, l’idée est vraiment très bonne ! En plus elle tombe à pic et solutionne un problème que j’avais la veille.

Dommage que la proposition ne soit pas passée et même si je comprend les raisons, on fait bien ce qu’on veut avec nos APIS !

Encore un bon article donc :-)

D’un côté dans un helpers.py:

# en lecture, je veux l'objet complet, pas juste l'id
def to_representation(self, value):
    return self.serializer_class(value).data

# petite astuce perso et pas obligatoire pour permettre de taper moins
# de code: lui faire prendre le queryset du model du serializer
# automatiquement. Je suis lazy
def get_queryset(self):
    if self.queryset:
        return self.queryset
    return self.serializer_class.Meta.model.objects.all()

# Get choices est utilisé par l'autodoc DRF et s'attend à ce que
# to_representation() retourne un ID ce qui fait tout planter. On
# réécrit le truc pour utiliser item.pk au lieu de to_representation()
def get_choices(self, cutoff=None):
    queryset = self.get_queryset()
    if queryset is None:
        return {}

    if cutoff is not None:
        queryset = queryset[:cutoff]

    return OrderedDict([
        (
            item.pk,
            self.display_value(item)
        )
        for item in queryset
    ])

# DRF saute certaines validations quand il n'y a que l'id, et comme ce
# n'est pas le cas ici, tout plante. On désactive ça.
def use_pk_only_optimization(self):
    return False

# Un petit constructeur pour générer le field depuis un serializer. lazy,
# lazy, lazy...
@classmethod
def from_serializer(cls, serializer, name=None, args=(), kwargs={}):
    if name is None:
        name = f"{serializer.__name__}AsymetricAutoField"

    return type(name, (cls,), {"serializer_class": serializer})

Et dans serializers.py:

bar = AsymetricRelatedField.from_serializer(BarSerializer)()

class Meta:
    model = Foo
    field=('bar', 'name')

class FooSerializer(serilizers.ModelSerializer):
    
    bar = BarSerializer(read_only=True)
    bar_id = serializers.PrimaryKeyRelatedField(source='bar',  queryset=Bar.objects.all(), )

    class Meta:

        model = Foo
        fields = ('bar', 'bar_id', )

Je m’embête depuis ce matin à trouver un truc propre, j’étais parti sur la solution 1, mais effectivement, refaire l’écriture à la main, c’est pas la joie.

Merci pour l’astuce.