Reprise du message précédent :
c'est ce que je me disais, mais le debugger me montre qu'il se fait bien sur le BufferedInputStream prévu a cet effet, et je l'ai crée avec taille de buffer == taille du fichier, donc il devrait pas.

REPLACE, c'est spécifique à MySQL ? Car j'ai l'impression que sur H2, ça passe pas. mais surtout, dans la doc, ils en parlent pas. Et personne semble avoir essayé de faire un REPLACE sur cette db (donc je sais pas trop si c'est supporté ou non car personne n'en parle...)

http://msdn.microsoft.com/en-us/library/ms186862.aspx ?

edit: mais je trouve rien dans la doc de postgres

je pensais plutôt à  

http://dev.mysql.com/doc/refman/5.0/fr/replace.html

Ca m'a tout l'air d'être une extension spécifique MySQL: je trouve rien dans la doc Postgres, ou dans le diff entre SQL2003 et Postgres.

C'est quoi cette syntaxe toute moche ?

c quoi la différence entre REPLACE et UPDATE ?

REPLACE fait un DELETE si l'enregistrement existe puis un INSERT. Et juste un INSERT si il n'existe pas. (chose qu'update ne fait pas)

  Ca, c'est de l'argumentation

=> C'est pas du SQL standard.
=> Ca a une semantique de merde...
=> Si on sais ce qu'on code on sais quand on doit INSERT et quand on doit UPDATE... Pour les cas specifique ou un "REPLACE" serait utile un DELETE a la main est plus parlant.
=> Le risque qu'on fasse un REPLACE tout le temps est un peu gros comme une maison...

Ca a jamais gêné personne l'introduction d'extensions au SQL.

Bof, c'est sensiblement la même que INSERT OR UPDATE

Pas nécessairement. On peut le savoir après un test (e.g. si une valeur persistée a un ID), mais ça ne veut pas dire qu'on a envie de s'emmerder avec ça, et d'augmenter le volume de code pour rien.

Si l'objet est bien codé tu fait :
 

 
Donc t'as bien deux méthodes qui font 2 requetes distinctes...

my_object.ensurePersistent -> REPLACE  
 
c'est moins de code et pas spécialement plus crade non ?

C'est bien ce que je disais, c'est moche et ça sert à rien

 
Ou my_object.save(). Qui va faire un "replace", un "insert or update" ou un check manuel selon la db, mais dont la sémantique correspond complètement à "replace"/"insert or update"

+1 avec Masklinn : ça peut etre sympa de découpler ton implémentation de ce que peut faire/ne pas faire ton SGBD du moment, même si par XP tu changes assez rarement de SGBD en plein milieu d'un projet, en tout cas rarement de marque (tu peux passer de Oracle X à X+1, tu vas rarement passer de Oracle à MSSQL)

Non, mais tu peux avoir ta prod sous Oracle paske c'est super bien et que t'as 5 sysadmins dessus à plein temps et les machines de dev backée par du SQLite, du HSQLDB ou du Postgres en local parce que c'est vachement plus léger et que ça évite de devoir se payer des licenses à toutplein de brouzoufs, tout en permettant aux devs de bosser sans se marcher sur les pieds (e.g. sans tous taper sur la même db)

En plus, ça libère de sql*plus.

oui mais non : je trouve ça dangereux de pas dev sur le même environnement que la prod (surtout un SGBD, c pas neutre du tout, tu peux avoir des effets de bord (gestion du 0/null/vide, perf de certaines requêtes par ex) et je prendrais carrément pas le risque)
 
avec le temps passer à devoir changer ta couche DAO pour l'adapter à X SGBD, le temps passer à pas comprendre pkoi ta requete Postgres qui tourne si bien foire comme une merde sous Oracle, ça te paye la license de dev
 
ensuite quand ta boite a les moyens d'être sous Oracle, c pas monter une instance de plus qui va ruiner la boutique...sur le truc sur lequel je bossais en stage, on avait 5 environnements, et 4-5 serveurs Oracles différents, 3 serveurs SAP (32 proc, une espèce de monstre), et 3 mainframe

Juste comme ça, Oracle XE c'est gratos, et ça suffit souvent pour le dev.
 
Sinon l'ideal c'est quand meme d'avoir des requetes le plus possible dans le standard SQL "just in case"...

on en revient tjs au meme débat : Oracle c ultra documenté, tlm connait, tu trouves hyper facilement des DBA Oracle, etc...

c'est de la merde en barres, oui

peut etre, mais de la merde prédictible et supportée...
 
qd t une grosse boite et que tu payes Oracle, tu peux acheter un consultant Oracle et le forcer à dormir dans la salle serveur tant qu'il a pas trouvé de quoi vient le problème, et ce parce que ta boite paye...
 
en open source, tu poses ta question, ben si personne veut te répondre c'est dans ton cul : tu peux avoir ta réponse en 3 secondes comme jamais : ce n'est pas prédictible, c'est pas décideur compliant

Et surtout Oracle ça scale super bien sur les gros volumes de données et avec plein de RAM/CPU...

 
Que c'est humain  

 
Tu symbolises, à toi seul, la caricature même du manager qui parle de choses dont il n'a plus AUCUNE idée de leur application réelle.

Quand tu utilises un ORM correct, il gère ça pour toi. Quand tu utilises pas un ORM, tu te fais des DAO injectés propres capables de gérer ça pour toi. Et c'est le DBA oracle qui se tape le DAO Oracle.

Oui mais non, si tu fais du multibase soit tu utilises un ORM soit tu as deux DAO et tu injectes le bon dans le bon environnement

T'es gentil mais je parlais de une instance Oracle pour chaque dev, si t'as 10 devs ça veut dire 10 bases Oracle...

Et ça prend 600Mo de RAM avant de commencer à faire quoi que ce soit

Heuu bof hein, c'est comme PHP, ça devient prédictible quand t'as passé des années à te manger les comportements non prédictibles en full frontal et que t'as fini par tous les connaître par coeur.

On est pas encore vendredi garçon, si t'as envie de payer il est trivial de trouver des consultants pour MySQL (ya MySQL AB déjà), Postgresql ou même sqlite si t'as rien de mieux à foutre

Sauf que c'est pas le seul truc qui scale bien sur de gros volumes  
 
Genre Postgresql est souvent utilisé pour des volumes de l'ordre de la demi-douzaine de To (c'est dans ces eaux là qu'il commence à avoir des problèmes, mais le boulot à démarrer pour améliorer la scalabilité gros volumes dans 8.4 et suivant). Oracle monte plus haut, mais entre 25To et 100To (selon le nombre et la qualité des DBAs et la taille du hardware que tu peux lui filer) il va aussi commencer à avoir de gros problème, après faut passer sur du non relationel (e.g. BigTable) ou des solutions spécifiques. Genre Yahoo tourne sur un fork de postgres, ils ont 2PB de données, et 25 milliards d'évènements par jour

depuis quand on prend au premier degrés ce qui est posté ici ?

je vous retourne le compliment : vous parlez de la composante technique pure, en faisant TOTALEMENT abstraction de toutes les autres dimensions (économiques, risque stratégique, etc...)

on a des systèmes de prod qui tournent avec des bases Oracle (jusque là rien de mirobolant). On a un petit soucis : notre carnet de commande est plein à 11 mois sur certains modèles. Ca veut dire quoi ? ça veut dire que si tu commandes un camion, tu l'as dans 11 mois, cad le planning de prod est plein.
Quand on a une panne mettons d'1h, on perd par exemple 4 camions...ces camions sont perdus, parce que qd tu vas voir le client et que tu lui dit : on s'excuse hein, mais on peut vous relivrer que dans 11 mois, ben tu perds la vente...donc on perd la facturation de 4 camions, et c'est un manque à gagner pour l'entreprise.
Je te passe la perte d'image de marque, les pertes liées (si tu vends pas le camion, tu vends pas les services autour sur lesquels on se fait notre marge), les pertes de PDM et les actionnaires qui gueulent, etc...

admettons que tu es 4 pannes Oracle dans l'année (que ce soit lié à Oracle ou au hard qui supporte les hotels Oracles), ben les managers comme tu dis apprécient une certaine prédictibilité dans le temps de résolution. Si chaque panne prend mettons 1h à résoudre, tu perds 4h de prod,donc ~16 camions : c'est dur, mais c'est prévisible.
Sur un truc sur lequel t'as pas de support avec des SLA impliquant un temps de résolution max sous peine d'astreinte, tu peux avoir le pb résolu en 5 min, comme en 15h...et ça c'est un risque du point de vue du management : tu as un risque que ton problème ne soit pas résolu, et ce n'est pas acceptable vu le cout de ce risque...

donc traitez moi de manager tant que vous voulez, mais c'est précisément là que réside l'intéret de mon double profil : quand on me parle de DB, de qualité d'implémentation des normes SQL, etc... je comprends très bien de quoi il s'agit (pour avoir utilisé Oracle, PostGRES, Firebird, Access (sisi ))...mais qd un manager me parle de cout liés au risque, de prévisions des risques, de manque à gagner, etc...je comprends aussi ce qu'il me dit, et je l'envois pas chier comme un techos de base en lui disant : pffff, la solution que tu veux qu'on prenne c pas la meilleure techniquement, t'es qu'un con

l'open source fait peur aux grosses boites, parce que la partie support est floue : la communauté, ça fait pas bander un manager, parce que ça a un aspect roulette russe qui lui plait pas énormément...d'ailleurs le nerf de la guerre des grosses boites Open source, c'est précisément d'avoir su vendre un support jugé crédible par les grosses boites

je concluerai par une petite note sarcastique en disant que l'info reste un outil qui sert à résoudre des problèmes, et dans le cadre d'une entreprise, à résoudre des problèmes liés à la gestion ou à la prod. Faire de la technique pour l'outil, c'est un peu perdre de vue la raison première pour laquelle tu fais de l'info...
quand un gars te demande un outil pour gérer son appro de pièce en bord de ligne, il s'en branle velu que tu prennes ton pied sur le top niveau des SGBD. Il veut un truc qui marche, avec un cout raisonnable, et qui ait le minimum de downtime en prod parce que sinon ça bloque la ligne...

Non elle est pas floue, ya des boites complètes basées sur le service de faire du support pour les produits OSS? suffit de se renseigner avant d'acheter

Ca reste qu'on a beau faire du support dessus, si y'a un gros bug, y'a pas l'assurance de trouver quelqu'un qui saura le corriger...

Pas plus que sous Oracle effectivement, quand on a un gros bug on a jamais l'assurance que quelqu'un saura le corriger

=> Y'a plus de chance qu'il soit repertorié
=> Y'a plus de chance qu'il y ai un workaround
=> Y'a une assurance que Oracle aura les moyens de chercher sa source tandis qu'en OpenSource, a moins de trouver un dev. du projet qui aura le temps/l'envie de chercher....

non, non et oui mais aucune assurance que Oracle en aura envie. Donc non.

Mais ouais, bien sur.  
C'est pour ca qu'une des plus grosses boite IT de belgique s'est faite gentillement remballer par Oracle pour la resolution d'un bug present dans XML_DB (produit d'Oracle) qui est present depuis plus de 3 ans. Et le workaround propose par Oracle etait... de ne pas utiliser XML_DB...
 
Jubi > tu me fais marrer. A croire qu'il n'y a que les managers qui ont des planning et des evaluation de risque a gerer. On dirait l'un de ses jeunes loups aux dents longues et brillantes qui vient regulierement nous voir, nous demande en passant si la technologie XY est interessante, n'ecoute pas plus loin que "oui" ou  "non", creer un joli powerpoint pour dire a son superieur que la-dite revolutionnaire technologie sera impementee dans le tout nouveau produit bling-bling dans 15 jours. Resultat, quand ils reviennent pour nous demander le truc dans l'urgence et qu'on leur reponds que ce n'est pas possible avant 3 mois, alors c'est la panique, il risque de ne pas avoir le joli petit trophe en plexi-glas pour "bons et loyaux services" rendus a la societe.
Oracle, c'est loin d'etre la panacee, c'est meme une grosse merde. C'est hyper documente, mais encore heureux, vu qu'il introduisent des backward incompatibilites entre des versions mineurs! Et je ne parle meme pas de ton allusion au fait que l'on trouve des DBA Oracle a la pelle; c'est aussi vrai que pour les dev java: On en trouve a tous les coins de rue, mais pour en trouver un bon, faut faire du chemin.

+1
 

de 2 choses l'une :  
- Oracle prend le bug, et le corrige
- Oracle répond : work as designed, et dans 90% des cas te proposera de te développer la "feature" qui manque moyennant paiement. Si c'est critique, tu paieras (modèle économique de quasiment tous les softs sur étagère, tous domaines confondus)
 

et bien sur c'est impossible que ce cas représente une minorité, parce qu'Oracle c'est vraiment des salauds mangeurs d'enfants, et d'ailleurs personne l'utilise à cause de ça    
 

 
You couldn't be more wrong : je ne suis pas impliqué dans les choix technos sur les progiciels que je gère pour ma boite, la gouvernance IT a shooté un fournisseur, moi j'assure la relation fournisseur et je suis l'interface entre mon groupe et ce fournisseur...au passage je fais du pognon avec le modèle économique qu'on a mis en place...
je fais 0 choix technologiques, je ne développe plus (sauf 3-4j / an pour un outil sur lequel je bosserai bientot même plus)...
Mais ça me fait toujours rigoler de voir comment la plupart des dev/ingé arrivent pas à s'extraire des problématiques purement techniques pour voir ce qu'il y a autour...et j'en ai plein autour de moi des gars comme ça, ayant plus de 40 ans et faisant toujours du dev, et qui ne sont pas montés parce que leur "intégrisme" technique les a plombé (j'ai vu un client sortir énervé d'une salle de réunion poursuivi par le CP qui essayait de le calmer parce qu'un de ces gars "technique" l'avait limite traité de con parce que la prise en compte de ses contraintes business allait conduire à prendre une solution qualifiée d'"hérésie" technique...
 
je dis pas pour autant que les managers ont toujours raison et que des fois ils font pas authentiquement des choix à la con, mais je cautionne pas le parti pris qui est de dire : décision de manager = connerie 100% du temps
 
Tu noteras aussi ta déformation de mes propos : y'a une différence énorme voire un monde entre "oracle c'est la panacée" (ce que je n'ai jamais dit), et "les boites préfèrent Oracle ou MS SQL parce que c'est facilement supporté, et prédictible au niveau des risques"...
 
Pour le troll DBA/Java, je marcherai pas dedans, même du pied gauche

On est super content pour toi. Maintenant, si tu veux bien relire le titre du sujet, ca me ferait plaisir.

En même temps une grosse boite d'IT Belge c'est sans doute une mini boite pour Oracle...

T'as oublié les cas "oracle prend le bug et t'envoie chier pour le corriger" et "oracle prend le bug et t'explique que ça sera corrigé dans Oracle 12, t'auras qu'à te payer l'upgrade".

C'est pas un problème de minorité ou majorité, c'est un problème de FUD de votre part

Et donc au final le support oracle et autres conneries c'est valable que pour les très très très gros clients? Ah ben tout de suite c'est génial

edit: fin de la conversation pour autant que je sois concerné, désolé Lorill.

 
viendez les boobs ?

Le problème, c'est pas d'utiliser des produits Open source ou non, cher ou non, juste qu'Oracle vend un produit qui à l'air assez moisi (mais connu)

 
tof !
 
Jubi > relis toi ya 3 ans, t'en en train de partir en quenouille exactement comme le dit gizmo
 
lorill > rabat joie

Il y aurait moyen d'avoir une argumentation de ce fait quelquepart dans ce forum ou ailleurs ?
Ca m'intéresse.
Merci.