configuration qui génèrent des instances de connexions?

[gyom]

Dans config.py on a le code suivant.

class MongoConfig(BaseModel):
    url: str
    database: str

    @cached_property
    def instance(self):
        from pymongo import MongoClient

        client = MongoClient(self.url)
        return client.get_database(self.database)

Conceptuellement, c'est vraiment bizarre. Je comprends l'idée d'avoir une classe de configuration qui permet de faire des choses connexes, mais pour moi, une classe qui représente la configuration pour MongoDB, ça n'a pas une méthode instance qui retourne un client vers un serveur MongoDB. Une "instance" ça évoque l'idée d'une instance de la classe configuration, peut-être, mais même là c'est à se demander pourquoi.

Je verrais plus une méthode get_mongo_client(cfg) ou quelque chose du genre, qui existe à l'extérieur.

Par ailleurs, le membre "url" est un peu mal nommé. On parle de "connection string" souvent dans le contexte de MongoDB, et ça implique parfois des options particulières pour se brancher. Par exemple, ici on trouve cet exemple.

conn_str = "mongodb+srv://<username>:<password>@<cluster-address>/test?retryWrites=true&w=majority"

J'ouvre la "discussion" ici pour donner l'opportunité aux gens de commenter avant que je ne change le nom pour "connection_string" dans la configuration, si qqun a une opinion sur ça.

[bouthilx]

url -> uri

[bouthilx]

Je sais pas trop pour la questions d'instance mongodb ou connection ssh. Je trouve ça pratique de pouvoir aller chercher les objets instanciés à partir de la configuration directement plutôt que devoir importer des functions pour les créer. Pour avoir une fonctionnalité équivalente faudrait aussi cacher les fonctions comme c'est le cas pour les instances.

[gyom]

C'est pratique, ok, mais conceptuellement c'est bizarre.

Si j'ai un BiscuitsConfig, dis-moi ce que "instance" retourne?

Un carte index avec la recette? Un biscuit fait avec la recette? Une bouche en train d'en manger? Une cafétéria où ils en vendent?

Est-ce que vous tenez au mot instance dans ce cas? Est-ce que, au moins, on pourrait appeler ça get_client et ça vous irait?

[gyom]

Ou si on ne prend pas get_client, alors get_client_database vu que le code fait

    client = MongoClient(self.url)
    return client.get_database(self.database)

Mais pas instance si ce n'est pas une affaire forcée par BaseModel et autres.

[bouthilx]

get_client ça m'irait.

Clairement BiscuitsConfig.instance ça retourne un biscuit. :)

[breuleux]

J'aurais tendance à renommer database vers database_name et instance vers database.

[gyom]

Ça je trouve que ça sonne mieux.

[breuleux]

+1 pour uri. J'ai conçu le truc comme ça parce que je trouve ça plus convivial et facile à utiliser, mais MongoConfig est peut-être pas un bon nom de classe.

[gyom]

Ouais, ok pour URI, mais il me semble que "connection_string" c'est absolument clair quel rôle ça joue dans le contexte de MongoDB. Quand je vois "URI" je ne sais pas si c'est juste l'adresse du serveur, si ça a un username/password, et ainsi de suite, mais avec "connection_string" c'est clair que ça doit comprendre tout ce qui est nécessaire pour se brancher.

[bouthilx]

Quand je vois connection_string la première question qui me vient c'est est-ce que c'est un URI? 🤷‍♂️

[gyom]

Et la réponse c'est que oui, c'est un URI, mais la possibilité de fournir un mot de passe dans un URI est supposément deprecated, alors est-ce que c'est réellement un URI? C'est pas mal plus facile de dire que c'est whatever que tu as besoin de donner pour te brancher avec l'application Compass ou avec un Client de pymongo.

https://en.wikipedia.org/wiki/Uniform_Resource_Identifier

Use of the format username:password in the userinfo subcomponent is deprecated for security reasons.

[gyom]

Le nom de la classe MongoConfig me semble bon. Faut juste pas utiliser le nom instance en-dessous et tout est correct.

Ça me plait aussi d'avoir les classes au lieu d'avoir du JSON en main. Je comprends l'utilité. Faut juste continuer de les traiter comme des bouts de configuration, il me semble.

[gyom]

Je pense que je viens de comprendre quelque chose.

mais MongoConfig est peut-être pas un bon nom de classe.

Moi je trouvais que tu faisais des choses bizarres avec ta configuration. Le nom "MongoConfig" était correct, mais pas ce que tu en faisais. Là je crois comprendre que, dans le fond, tu voulais faire un objet pratique qui n'était pas une "configuration" mais qui était issu de la configuration était, d'où le choix de nom "MongoConfig" qui serait mauvais. Et là, ce n'est pas bizarre maintenant si cet objet lui-même crache des instances singleton de connexions.