Reprise du message précédent :
J'en peux plus de Typeorm laaaaaa.    
 
Chaque mise en prod, ce truc délire complet.
 
Je dois mettre à jour la prod d'un vieuuuuuux projet. Typeorm init la base, je charge le dump, typeorm dit qu'il manque des tables alors qu'elles sont là.
Je charge le dump avant, je sync la base (y'a plein de nouvelles colonnes), typeorm plante à cause des clés primaires et foreign key qui sont pas les mêmes selon SES init et la bdd.
 
 
/ragequit.
 
 
Et bien sur, ce comportement est aléatoire.

l'aléatoire en informatique, c'est soit que tu as réussi à inventer une source de nombre aléatoire (et là tu es riches) , soit que tut utilises de la magie que tu ne comprends pas

Je comprends surtout pas TypeORM, vraiment merdique ce truc. 2 ans que je le dis, 2 ans que je continue à l'utiliser. On dirait Harko et le Java.
 
 
 
BTW, j'ai résolu le soucis. Export SIMPLEMENT les datas de la base, sync de typeorm pour refaire une base propre avec les nvx champs, et load des anciennes data dans les colonnes qui vont bien.

Les orm, c'est le mal
</skeyz>

 

 
Je me suis remis à Doctrine depuis quelques mois, et ça me réjouit pas particulièrement.

Vive l'ORM Django  

Il fait quoi de si bien par rapport aux autres?

C'est pas lui, c'est plutôt moi    
Je sais bien l'utiliser (syndrome de Stockholm).
 
Ce que j'apprécie particulièrement :
- les migrations
- la maturité générale et son degré de complétion (on peut faire bcp de choses)
- les checks : https://docs.djangoproject.com/en/2.2/ref/checks/#mysql
 
Le requêtage / API n'est pas vraiment plus simple que du SQL mais la possibilité de travailler avec les objets Django est important pour moi.
 
J'aime le voir aussi comme un point de passage en terme d'abstraction :
 
-Si je fais passer toutes mes requêtes via l'ORM, je dispose de tout un tooling plus haut niveau plus proche du framework (stats sur les requêtes par vue, ..).
 
Si je veux intégrer une nouveau type de base de donnée, j'essaye d'imaginer l'implémentation d'un backend (même incomplet) qui va me permettre d'implémenter des premières requêtes façon Django
ça me permet de stocker certaines données ailleurs et avec un peu de chance que certaines pages fonctionnent toujours

Je suis assez d'accord avec BenO, l'ORM de Django a atteint, je trouve, un bon compromis : il est assez puissant pour faire des requêtes un minimum complexe, t'es pas obligé de repasser au raw SQL dès que t'as besoin de faire des jointures un peu poussées ou des query d'agregations.... sans avoir la complexité d'un SQLAlchemy, certes très puissant, mais dont la courbe d'apprentissage est quand même horrible, et qui sera sous utilisé par 80% des gens imho.

Te plains pas, tu pourrais utiliser Hibernate

J'utilise jpa / hibernate pour pas avoir à chier le code de lecture / écriture des entity mais ça se limite à du crud, pour le reste j'utilise jooq et je désactive l'update de la base, je configure le JPA pour qu'il ne génère jamais aucun nom à la con du genre FK_mescouillessurtonnez3543321235236, et je gère les maj avec liquibase  
pour les requêtes complexes je fais du jooq mais j'avoue avoir surtout de la lecture à faire dans ces cas.  
 
le gros incovénient est d'avoir une stack horrible avec 5 projet maven pour juste un truc de base mais quelque part, tu contrôle tout en prod et je vois pas comment gérer proprement les versions de base dissociées de la version de l'appli sans s'astreindre à faire ça
 
comme pour git, c'est peut-être une forme d'abandon des possibilités de la techno, c'est peut être pas optimisé par rapport à tout ce qu'offre jpa / hibernate mais putain la tranquilité de pas tomber dans le cas du "mon update de base échoue et je ne sais pas pourquoi"
 
parfois je me dit que je devrais tout virer et mettre que jooq mais j'aime bien les converters et la gestion des blob jpa est pas si dégueu.

 
Balance le compte

http://instagram.com/amysbakingcompany/

 
Je pense que t'as la bonne approche. T'utilises certes plusieurs outils/libs, mais chacun pour une tâche précise qu'il fait bien.

 
Doctrine est très bien pour des projets relativement simples avec du pur symfony. Pour les projets extrêmement complexes nécessitant énormément de requêtes différentes, de jointures complexes etc... C'est pas adapté (après genre quasi 8 ans de recul)
Au boulot, on a donc deux types de projets :
- Les projets purs symfony où l'on utilise Doctrine.
- Les projets où l'on utilise certaines librairies de symfony comme http-Foundation, validator etc... en dehors de symfony lui-même. On utilise alors une simple librairie pour gérer toutes nos requêtes db pdo. C'est mille fois plus lisible et compréhensible, bcp plus ouvert et au final, c'est plus facile à maintenir aussi. On le vérifie avec nos projets qui ont plus de quelques années... Également, le code est bcp plus facile à maintenir car on upgrade les librairies manuellement avec composer et on sait exactement l'impact sur le reste du code. Et comme on a que du pur SQL, on a pas de problème non plus à ce niveau là.

 
Putain ils continuent de se faire insulter
Les gens sérieux

Tu peux très bien utiliser Symfony avec Doctrine DBAL. Je ne vois pas le rapport entre le fait de ne pas utiliser Symfony si tu n'utilises pas Doctrine ORM

 
Je sais cela. Dans nos très gros projets, Doctrine n'est pas la seule chose qui rend compliquée la maintenance du projet sur le moyen/long terme. On a maintenant des années de recul et on voit parfaitement ce qui se passe avec nos projets pure Symfony et les autres projets. On ose pas mettre à jour Symfony sur un gros projet qui marche par exemple, c'est toujours un vrai stress, même si en théorie ça devrait être simple. En pratique, ça ne l'est jamais.
Mais on continue à faire du pur symfony pour des projets pas trop gros.

Je suis en train de me perdre dans Reddit

Alors Flo, t'aime nos bureaux ? Ça va, je crois qu'on fait pas trop startup kikoolol

J'allais écrire que @plamcorp c'est une vraie boîte
Ou alors tu as trouvé des figurants crédibles
Les locaux sont très sympa , et les gens aussi (mais je les connaissais déjà)

Comment ça Flo est à Grenoble ?

Bah salut.

T'as essayé Trou DBAL ?

 
harkoG

 
Imagine. Il a une fille.  

 
Ça marche pas avec le Mac du nouveau comme doctrine.

 
J'ai loupé un calembour ?

A propos de fille...  
 
Au mariage d'un pote il ya  2 semaines, il y avait 2 de ses anciens potes de promo, dont un qui s'est marié avec leur prof d'allemand de l'époque.
 
du coup, il a des enfants beaucoup plus âgés que la moyenne pour son âge (en gros, il a 40 ans, et 2 filles de 16 et 17 ans. Rien d'extraordinaire non plus, mais bon)
 
Au cours du repas, le second pote (accompagné de sa femme, qui était placée entre eux) lui a sorti :  
 
"C'est marrant, elles sont très différentes tes filles... Machine elle a un type plutôt scandinave, alors que Trucmuche c'est plutôt mon fantasme d'Allemande"
 

Bah yes. Un plaisir de manger avec ce mec et de savoir que ta fille c’est son fantasme.  

 
DBAL, déballe ?

J'ai eu plein de dumps d'imprimantes, mais je n'ai pas eu de lexmark/hp/oki
Si quelqu'un à ça, je suis preneur

(il me faut un fichier avec des oid du genre 1.3.3452.4365.3546.53. et leur valeur)

 
Alerte crise de la quarantaine + alerte gros sac
 

 
Harko is strong with this one

 
J'ai une LexMark CX517DE et une OfficeJet Pro 8710. Je sais pas si ça peut t'intéresser.

So
Si ça t’intéresse, linke moi la commande à taper.

Mercredi j’aurai access à une imprimante plus pro aussi, laserjet couleur recto-verso, ça sera plus y’a cible (HP Color LaserJet CP5520).

ho oui

snmpwalk -v2c -On -c public IP-DU_COPIEUR .

le . au bout est utile

Dans tous les cas, si elles supporte snmp, je veux bien.

https://gist.github.com/nraynaud/40 [...] 3e8c331246
 
rappelle-moi mercredi pour l'autre imprimante.

nico: elle est en panne d'encre ?

Avant HP te pétait les couilles sur le panneau de l'imprimante et dans la boite de dialogue du driver, mais maintenant ils viennent te harceler sur les forums
 
NON ELLE IMPRIME TRES BIEN, C'EST UN COMPLOT DES VENDEURS DE CARTOUCHES.
 
(oui, elle me pète les couilles avec "tonner bas" depuis des mois)