Reprise du message précédent :

 
Oui et justement, je demande pourquoi ? Car une fois que tes stored procedures sont en place, tu peux les appeler, elles sont bien séparées du code, elles sont faciles à maintenir, en terme de sécurité, nickel... Et finalement les ORMs, c'est pas si différent que cela au niveau du résultat.

c'était un appeau à Alt, je savais que tu répondrais à ça
 

je connais cette théorie    
 
En pratique j'aimerais qu'on me donne un exemple de cas où le seul changement dans le code résultant d'une migration, c'est de changer le nom du driver / de la DB dans la config de l'ORM.

Mouais... les stored procedures, c'est quand même pas trop ça niveau facilité de debuggage

C'est chiant à maintenir, c'est un truc en plus à versionner avec ton appli "cliente", coté appelant tu n'as pas forcément une vision claire de ce que ça fait, si t'as besoin de customiser un truc pour une fonctionnalité précise de ton appli tu vas devoir implémenter une SP dédiée là où t'aurais peut-être avec un ORM juste écrit une requête native...
Les rares fois où j'en ai utilisé ces dernières années c'était pour des traitements type batchs sur des gros volumes pour gagner des perfs...

 
Faire pondre à un ORM une requête "optimisée" pour certains traitements est un des trucs qui m'a fait perdre le plus de temps à une époque...obtenir des perfs acceptables sur des cas complexes est probablement le meilleur argument pour se passer d'ORM, vu d'ici.

• qu’elles soient séparées du code n’est pas un avantage, ça veut dire que tu partages la logique entre l’application et la DB
• ça implique qu’à chaque changement de logique tu peux devoir aller changer le schéma
• débugger de la logique qui est dans la DB tu fais difficilement plus chiant
• ça augmente la charge du serveur DB, généralement plus difficile à scaler que le serveur d’application
• si t’as de la logique dans la DB, ça rend la gestion de cache plus compliquée

Et l’ORM fait la gestion du schéma et la désérialisation en types applicatifs, ce que ta stored proc va jamais faire, donc tu dois faire le mapping manuellement dans les deux sens avant d’appeler ta proc.

J’ai jamais vu, mais pour moi c’est un peu si t’as 95% des requêtes qui sont faites via l’ORM t’as pas besoin de les regarder si tu migres, et tu te fais juste chier avec les 5% qui restent.
 
Après les migrations de data store j’ai jamais vu, hors utiliser sqlite pour faire tourner les tests.

Sauf qu'une requête SQL, il y a toujours moyen de l'optimiser. Un accès via ORM, c'est simplement pas possible. Du moins pour ceux qui construisent la requête eux-mêmes.

 
Les procédures stockées faciles à maintenir ? Par rapport à ton code applicatif standard il y a de la friction supplémentaire pour leur déploiement et leur gestion de version, elles sont plus compliquées à debug, plus compliquées à tester correctement et le skillset nécessaire à leur écriture est probablement beaucoup plus restreint que pour le langage dans lequel tu développes.
 
Je les range dans la même catégorie que les regex complexes : ne les utiliser que si c'est absolument nécessaire et qu'il n'y a pas d'alternative valable.

De toute façon en 2025 c'est chatgpt qui fait le sql alors ça va

C’est fini le temps où tu remplissais un dossier pour demander au bureau des DBA de t’écrire une requête

Dans 90% des cas les trucs que tu peux changer en SQL tu peux aussi les changer via un ORM.  
 
T’façon dans tous les cas le planner peut décider de t’envoyer chier et plomber ta requête du jour au lendemain parce qu’il est pas content.

il y a moyen de forcer la main aux ORMs aussi en règle générale, mais la question devient rapidement "pourquoi je bataille à faire générer à un ORM la requête que je sais très bien écrire moi même, là, au fait? "

Ca dépend pas mal du niveau de support des bases, mais je n'ai pas eu de problème avec Hibernate, par exemple.

Comme je l'ai dit, ça m'est arrivé une fois, le jour où je me suis aperçu que la licence de MySQL était incompatible avec l'utilisaton qu'on en faisait (c'était avant MariaDB). On a dû tout migrer sous Postgres.

J'ai toujours résolu ce genre de problème par la construction d'un index dédié qui rend la requête triviale à écrire et rapide. C'est peut-être pas toujours faisable, c'est mon expérience.

Voila, c'est très rapidement la merde.
Pour ça que je considère que ce n'est pas fait pour faire de la performance mais du CRUD ou des requêtes un peu plus chiadées qui vont te retourner un nombre limité de lignes.

Aussi pour ça que le genre d'ORM que je préfère, ce sont ceux qui ne génèrent pas de code SQL, mais se contentent de simplifier le mapping, comme MyBatis en Java. Ce sont les moins sophistiqués, mais au moins on sait ce qui se passe.

S'attendre au pire permet de n'être jamais déçu mais il faut avouer qu'ils parviennent à garder des surprises  

 
le seul cas ou j'ai touché les limites des orms que j'ai utilisé, ce sont pour  
* des requetes de traitement batch, qui gagnaient a être faite en une passe, plutot que récuperer toutes les données dans le client et renvoyer le résultat dans la base .
* des gros aggregats un peu sales , avec des requêtes imbriquées

note que là t'es probablement plus vraiment dans l'ORM à proprement parler, mais j'imagine plutôt dans la couche d'abstraction qu'il fournit - typiquement tu génères du DQL doctrine / HQL hibernate plutôt que manipuler simplement les objets mappés.

 
Ok merci. Je comprends mieux.  

C'est quand même le pays qui a mis des sanctions à l'égard des juges du TPI. Et c'était sous Biden, si je ne m'abuse...

Ah, et comme Zelensky a annoncé qu'il ne se plierait jamais à un "accord de paix" signé derrière son dos, Trumpy est tout bougon parce qu'il ne verra pas son prix Nobel (les MAGAs qui lui lèchent les bottes vivent quand même dans une autre dimension s'ils s'imaginaient qu'il avait la moindre chance de le décrocher), il vient de dire que l'Ukraine n'aurait pas dû attaquer la Russie.

Bon maintenant que je vois un peu mieux les avantages pour un ORM, concernant Rust specifiquement ?
 
Parce que pour Python Flask sur lequel je travaille pour mes projets perso (je ne code plus rien professionnellement parlant, je suis à 100% dans le management), j'utilise SQLAlchemy avec PostgreSQL en dessous, mais pour Rust, en parcourant un peu les topics reddit et autres... J'ai pas l'impression qu'il existe un truc incontournable correctement supporté (ou en tous cas dans lequel on peut avoir confiance).
Best ORM for Rust donc d'après vous ? SeaORM ? Je vois qu'il existe des exemples avec Axum...

 
Tellement l'impression que je suis dans un épisode de constellation ou dans The Cloverfield Paradox quand tu redescends sur terre.        
 

Ça aussi c 'est pas mal : https://www.leparisien.fr/internati [...] YYB24I.php

T'as aussi les requêtes FOIA sur le DOGE qui ont échoué parce que les mecs chargés de les honorer ont été virés

 
+1 j'y crois pas du tout en dehors de toy projects triviaux ou d'applis pas en prod. J'ai fais une migration MySQL -> Postgre (on avait besoin du support géographique de Postgis qui n'avait pas d’équivalent dans MySQL) dans ma première boite y a 15 ans (on utilisait Django), ca nous a pris plusieurs semaines pour avoir une procédure de migration fiable et pourtant on s'autorisait du downtime.

en fait, Trump c'est Biff Tannen dans BTTF 2 !
"C'est moi qui lui donne des ordres à la police"  

Proton ?

Infomaniak https://www.infomaniak.com/fr/ksuite/kdrive

C'est pas cher !  

En payant via la Turquie mon Workspace me coûte rien

Carrément ! 3 To pour 5 €, c'est donné.

Hors taxe mais ca reste pas cher

Ca c'est devenu du "prévu" le depuis 15 jours

 
Beaucoup sont soit sous:
  - Diesel, mais pas async
  - SQLx, surtout pour le compile time verif
  - tokio postgres (pour les non-ORM, perso celui que j'utilise)

Un seul user !

il y a aussi pcloud en suisse, mais le modèle d'achat de storage "à vie" ressemble beaucoup trop à du scam

Fun Fact, dans BTTF 2, Tannen a bien été inspiré par Trump, déjà à l'époque. cf ‘Back To The Future’ writer reveals Biff Tannen was inspired by Donald Trump.

Roh putain, je savais pas en plus

Qu'est ce que tu fabriques Kenshineuh ? Ou c'est Harko qu'est déjà bourré et qui efface les posts au hasard ?
 
Et pas besoin d'un tel monstre, je visite juste les performances d'une 4090 dans pas mal de cas de figure, donc une 5070 non TI sera bien suffisante ! Les tests de cocowtland et de french hardware ne laisseront pas place au doute !

 
https://www.youtube.com/watch?v=PhtVic3Vm0Y
 
   
 

 
Peut être que la version normale sera plus puissante.