Les récentes indignations de "monty" Michael Widenius, créateur du gestionnaire de base de donnée mysql explique sur son blog en quoi le nouveau choix d'Oracle de basculer d'un logiciel open source (double licence oui mais pas trop désavantageux pour la communauté) vers un système open core (un socle minimal libre puis le reste propriétaire) est une mauvaise chose pour mysql.
Je trouve aussi que Oracle n'a soit vraiment pas retenu les leçons d'un proche passé ou alors s'en fout complétement (rayez la mention inutile).
Pour le détail, en anglais, c'est ici.
Après certes ils font ce qu'ils veulent mais avec la popularité de mysql (et le prix exorbitant des licences d'Oracle) ils risquent peut-être gros en cas de fork fructueux.
Sûr ce, bonne nuit !
# Postgresql
Posté par Altor . Évalué à 10. Dernière modification le 26 septembre 2011 à 22:46.
Je vois ça surtout comme l'occasion pour beaucoup d'infrastructures de migrer vers postgresql.
[^] # Re: Postgresql
Posté par hervé Couvelard . Évalué à -10.
c'est ce qui va se passer, mais c'est un choix stupide.
Il y a une différence de taille entre mysql et postgresql : la rapidité et l'empreinte mémoire. Mysql fait/faisait moins de choses que postgresl mais est/était beaucoup plus rapide dans les opérations de base.
postgresql est plus compliqué à gérer et à maintenir (par exemple les autoincrément c'est pas vraiment ca)
Maintenant oui postresql fait plus de choses, mais ce n'est sûrement pas un remplaçant à mysql.
[^] # Re: Postgresql
Posté par Fabien (site web personnel) . Évalué à 10.
J'aimerai bien savoir de quand datent tes observations concernant la rapidité.
Pour la complexité, je pense que ça dépendra de l'expérience de chacun.
Enfin moi, j'ai eu envie de pleurer quand j'ai essayé d'optimiser / tuner mysql (contraint de l'utiliser à cause de magento).
Pour les SERIAL, effectivement ça change des 'autoincrement' au début, mais c'est bien plus souple à l'usage.
Je pense qu'une des faiblesses de postgresql était la réplication, mais depuis la dernière version, on peux faire du asynchrone et même du synchrone (sans passer par drbd ou autre). Il ne lui manque plus que le mode cluster.
[^] # Re: Postgresql
Posté par Ontologia (site web personnel) . Évalué à 10.
J'appuie le témoignage de Fabien plus haut.
Pour avoir utilisé postgre dans le cadre d'une petit appli web, je peu te certifier que c'est non seulement très rapide, mais très facile à utiliser et installer.
Je pense qu'on va observer des migrations massives, et pas que du monde MySql. Mes antennes m'apprennent que ça migre un peu partout (Oracle -> Postgre), mais qu'on veut pas trop en parler, peur du qu'en-dira-t-on...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Postgresql
Posté par Galou (site web personnel) . Évalué à 3.
Je ne vois pas de quoi tu parles... J'ai toujours constaté de meilleures performances de PostgreSQL (vs MySQL). Quant à l'emprunte mémoire, je ne peux rien dire, je n'ai jamais comparé.
PostgreSQL gère un type SERIAL équivalent à l'autoincrement. Qu'apporte l'autoincrement en plus du serial ?
Il y a moins d'interface clicable pour configurer PostgreSQL en comparaison à MySQL. Mais une fois configuré (si on ne sait pas faire, on peut toujours laisser la configuration par défaut) tu n'as plus trop à y toucher. Je ne vois pas trop ce que tu entends par gérer/maintenir. Généralement, tu n'as pas trop à revenir dessus. Peut-être un VACUUM de temps en temps histoire de dire qu'on a géré/maintenu quelque chose.
Je l'ai utilisé sur des sites avec pas mal de visites (plusieurs dizaines de milliers de visiteurs uniques par jour) et pas mal d'accès à la base, et PostgreSQL ne bronche pas (bien sûr avec un serveur dédié et une configuration optimisée).
[^] # Re: Postgresql
Posté par Lebas Sébastien . Évalué à 10.
Bof, peu importe qu'il te l'emprunte, du moment qu'il te la rends après ...
(=> pour la peine, je vais emprunter la porte ;) )
[^] # Re: Postgresql
Posté par téthis . Évalué à 10.
Veille à ne pas l'empreinter en sortant trop rapidement
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: Postgresql
Posté par coid . Évalué à -9.
Bof…
Je cite :
http://www.developpez.net/forums/d1054712/bases-donnees/langage-sql/petit-benchmark-concession-mysql-postgresql-ms-sql-server-mysql-jusqua-6000-plus-lent/
[^] # Re: Postgresql
Posté par BFG . Évalué à 4.
Conclusion hâtive, puisqu'ils avouent comparer des algorithmes différents. Quand ils comparent les mêmes algorithmes sur les SGBDR différents, les résultats ne sont plus pareil :
Le lien complet : http://blog.developpez.com/sqlpro/p9821/langage-sql-norme/agregation-d-intervalles-en-sql-1/
[^] # Re: Postgresql
Posté par Christophe Turbout . Évalué à 4.
hmmmm developpez.com ... l'échec de panda, ne pas avoir supprimé ce site nul ...
comme d'habitude, une série de requêtes improbables avec une comparaison que sous windows sans aucune explication de paramètres avec des généralités en réponses sorties de leur contexte .... bref, un bench qui va rejoindre une longue lignée dans /dev/null
[^] # Re: Postgresql
Posté par coid . Évalué à 1.
Voilà un avis bien rude. Tu peux développer ?
En quoi, par exemple, serait-ce pire que le forum de Linuxfr ?
[^] # Re: Postgresql
Posté par Christophe Turbout . Évalué à 0.
tu as déjà trouvé une réponse sensée sur ce site ?
pas moi ...
[^] # Re: Postgresql
Posté par oao . Évalué à 2.
Sur linuxfr ? Non jamais effectivement.
[^] # Re: Postgresql
Posté par Maclag . Évalué à 1.
sensée sur ce site
Voilà, comme ça, ici, c'est fait!
------------> [ ]
[^] # Re: Postgresql
Posté par kyusan . Évalué à 5.
Si tu utilises PostGreSQL comme MySQL, ce n'est pas plus dur à maintenir (je dirai même que c'est plus simple, rien que pour les outils de dump ou le client en ligne de commande). Et le jour ou tu veux aller plus loin tu n'es pas bloqué. Pour l'empreinte mémoire, ça se règle de manière assez précise.
PostGreSQL est vraiment un beau projet, qui marche bien mais qui se traîne une réputation de SGBD dur à maintenir alors que pour avoir goûté au trio MySQL/PostGreSQL/Oracle, PostGres est celui ou je prend le plus de plaisir à travailler avec.
(et va stocker des millisecondes dans MySQL :p )
[^] # Re: Postgresql
Posté par rewind (Mastodon) . Évalué à 4.
C'est vrai, quand on a goûté à PgAdmin3, on a du mal à revenir à PHPMyAdmin...
http://www.pgadmin.org/
[^] # Re: Postgresql
Posté par pasScott pasForstall . Évalué à -2.
Faut voir, oracle est pas un lapin de 3 jours quand il s'agit de vendre des licences, particulierement quand il s'agit de trouver le maximum qu'un client potentiel est pret a payer avant d'aller voir ailleurs.
Les commerciaux peuvent tres bien proposer un prix qui soit legerement inferieur a la migration. Ce qui va probablement seduire pas mal de responsables, parce qu'avouons le, une migration qui n'apporte rien de concret et qui peut potentiellement mal se passer, ca fait rever personne.
Entre la migration des donnees et le code ecrit avec les pieds qui va exploser en plein vol parce qu'un blaireau de presta offshore a trouve cool de mettre la session factory dans un singleton appele depuis 250 classes, yen a probablement qui vont y reflechir a deux fois.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Postgresql
Posté par windu.2b . Évalué à 0.
Primo : c'est pas le prix qui est le seul problème, mais le fait que seul le socle commun soit libre !
Secundo : que vient foutre ici cette histoire de singleton ? Qui a parlé de Java ?
[^] # Re: Postgresql
Posté par bibitte . Évalué à -10.
juste pour ta culture un singleton c'est pas réserver a java c'est juste un patron de conception que tu peux appliquer dans le langage que tu veux.
Si, si, même en python tu peux le faire!
Après si tu préfère continuer à coder avec les pieds c'est ton choix.
Pour plus d'info tu peux voir ici Singleton_(patron_de_conception) y'a plein d’implémentations dans plein de langages.
[^] # Re: Postgresql
Posté par flagos . Évalué à 0.
Merci pour ton ton pedant mais qu'est ce qui te fait dire qu'il ne connaissait pas le singleton ?
En quoi tu repond a sa question ?
Qu'est-ce qu'est venu faire cette histoire de Singleton et de Java dans cette histoire ?
[^] # Re: Postgresql
Posté par barmic . Évalué à -1.
Parce que le commentaire au quel il répond était courtois ?
D'une part il n'a pas parlé de Java, d'autre part il voulais donner un exemple de migration longue et lourde pour cause de couplage trop fort entre l'application et le SGBDR.
Mince « couplage » c'est un terme trop précis pour ne pas être considéré comme buzzword ici. Je rectifie :
D'une part il n'a pas parlé de Java, d'autre part il voulais donner un exemple de migration longue et lourde pour cause de code trop dépendant du SGBDR.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Postgresql
Posté par flagos . Évalué à 6.
Je connais pas Java et ses spécificités mais je ne vois toujours pas le rapport entre utiliser un Singleton pour gerer une SessionFactory et le couplage avec la DB !
La sessionFactry est juste la pour gerer les parametres de connections. Qu'est ce qui t'empecherait d'utiliser ensuite un systeme d'activerecord ?
La question est vraiment a prendre au premier degré: quel est le rapport entre le Singleton sur SessionFactory et la non portabilité vers un autre moteur ?
[^] # Re: Postgresql
Posté par bibitte . Évalué à -3.
je répondais juste sur le même ton que le commentaire au quel je reponds.
je répondais à la question "qui a parlé de java?" en disant de manière détourné que personne n'avait parlé de java mais juste le gars d'avant (pff) avait parlé de singleton et qu'un singleton ca veux pas dire java.
et au passage faire une petite réflexion java Vs python ça fait pas de mal pour ce faire moinser!
Moi j'ai rien a voir dans cette histoire.
Je pense qu'a la base que pff voulais dire que lors d'une migration de base c'est souvent galère a cause du gars qui a mis un singleton dans son code ou il fallait pas.
Au final mon commentaire n'était pas destiné à faire avancer le sujet du journal mais juste a faire remarquer à windu.2b que les singleton c'est pas forcement du java.
J'y suis peux être aller un peu fort sur la forme et pour moi c'était sur un ton un peu humoristique et j'assume.
C'est tout rien de plus.
[^] # Re: Postgresql
Posté par ckyl . Évalué à 6.
En même temps un singleton ça rentre souvent dans la catégorie coder avec ses pieds non ?
Fais attention, tu arrives quelques années en retard pour essayer d'être hype avec la locution patron de conception. Reviens 5 à 10 ans en arrière et t'es dans le coup.
[^] # Re: Postgresql
Posté par barmic . Évalué à 7.
C'est vrai que décrire ce que l'on fait c'est hasbeen. Toi tu préfère parler Scrum et agile pour faire du web 2.0 avec de l'AJAX ?
Je vois pas en quoi parler de patron de conception c'est has been. MVC est très utilisé et est une bonne méthode pour organiser son code. Expliquer à un collègue que l'on utilise une factory ou un proxy, c'est plus pratique. Vraiment je ne vois pas ce que tu leur reproche. Les frameworks (comme on en trouve pleins le noyau linux et sur le web avec Rail par exemple sur linuxfr) implémentent un tas de Design Patern, je vois pas en quoi c'est un mal.
Justement avant que tu fasse ton malin, il disait que quand c'était mal utilisé, il pouvait devenir difficile de changer de SGBD.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Postgresql
Posté par ckyl . Évalué à 0.
Non. Par contre pour scrum et agile t'as encore 3 ou 4 ans de retard pour essayer d'être hype.
On est en 2011 entre gens intelligents voir éduqués. Balancer un lien sur la définition du pattern singleton en disant grosso modo "Tiens apprend à coder propre" je trouve ça marrant. Et encore plus vu que le singleton c'est justement le plus mauvais pattern, il devrait mourir dans la douleur en enfer.
Tu sembles avoir du mal à lire les timestamps.
[^] # Re: Postgresql
Posté par lasher . Évalué à 4.
Balancer un lien sur Singleton n'est jamais perdu. Tu considères peut-etre que tout le monde sait en 2011 ce qu'est un Singleton. C'est faux. N'importe qui visitant ce site et regardant les commentaires peut ne pas savoir ce que c'est, et encore pire, avoir une idée confuse de ce qu'est ce pattern. Pour info, les informaticiens qui sont susceptibles de ne pas savoir ce qu'est un singleton sont légion:
[^] # Re: Postgresql
Posté par CrEv (site web personnel) . Évalué à 1.
Ha mais j'ai compris !
En fait tu est frustré car en tant que jeune développeur tu dois te taper des technos moisies (JEE, JSF) en utilisant des méthodes de développement archaïques dont on connait leurs limites et problèmes depuis quelques dizaines d'années.
Alors qu'en fait tu rêve de faire mumuse avec play!, jQuery et du NoSQL, le tout en utilisant du kanban (oui, scrum c'est déjà trop hasbeen).
Allez, soit pas triste, ça viendra un jour.
C'est bon, j'ai tout juste ? :-)
Bon, ok, c'était facile.
En fait c'est surtout que je n'ai pas bien compris le rapport entre décrire ce qu'on fait, parler de patterns, MVC, factory, toussa et le côté scrum/agile/ajax/...
En plus clair, tu semble opposer les deux alors que je ne comprend pas pourquoi, ce n'est pas du tout sur le même plan. Et on peut faire, par exemple, du beau serveur d'application (avec ou sans framework), avec des patterns "classiques", de l'ajax et développer le tout en suivant scrum.
[^] # Re: Postgresql
Posté par Antoine . Évalué à 2.
Oui, on peut faire des tas de conneries en Python, comme reproduire les lourdeurs inventées par les Javaistes (ou C++istes) pour contourner la rigidité de leur langage. Cela ne veut pas dire que c'est recommandé.
[^] # Re: Postgresql
Posté par pasScott pasForstall . Évalué à 1.
Que la db soit 100% libre, ca lui fera une belle jambe a la boite qui un systeme qui marchait bien et qui a investi plein de fric pour la migrer sous postgresql, et le responsable en question va y reflechir a deux fois avant d'aller expliquer a son boss qu'il a decide de claquer du fric pour faire une migration qui n'apportait rien et est risquee. En gros, il va pas risquer son taff pour un truc qui ne rapporte rien, il a probablement mieux a faire.
Quand au singleton et a java, c'etait une pique pour rappeler que changer un composant aussi essentiel ne se fait pas toujours en claquant des doigt.
J'ai prit l'exemple du singleton parce que c'est l'archetype du truc tres dur a changer quand il a ete mal utilise.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Postgresql
Posté par totof2000 . Évalué à 3.
Qui parle de migrer de mysql vers postgresql ? On peut très bien garder mysql pour les trucs qui existent déjà et partir sur PostgreSQL pour les nouvelles appli, ou migrer le SGBD dans le cadre de changement profond d'architecture.
[^] # Re: Postgresql
Posté par Matthieu . Évalué à 1.
Entre la migration des donnees et le code ecrit avec les pieds qui va exploser en plein vol parce qu'un blaireau de presta offshore a trouve cool de mettre la session factory dans un singleton appele depuis 250 classes, yen a probablement qui vont y reflechir a deux fois.
Et pourquoi ne pas mettre une session factory dans un singleton appelé depuis 250 classes ?
[^] # Re: Postgresql
Posté par ckyl . Évalué à 1.
Comment tu testes ton code ?
Trouver une utilisation justifiée du singleton est assez rare. En général ça te permet juste de faire un design moisi, avec beaucoup de couplage, un état global et un résultat impossible à tester.
Il y a énormément de documentation disponible sur pourquoi utiliser un singleton est le plus souvent une très mauvaise idée voir un anti-pattern.
[^] # Re: Postgresql
Posté par pasScott pasForstall . Évalué à -5.
Ah, merde, il etait serieux en plus, je pensais pas qu'on pouvait honnetement poser cette question en 2011, presque 12.
Bon, le singleton, c'est ok pour modeliser des resources qui sont effectivement uniques, de par leur nature.
Ta session factory, elle tout sauf unique par sa nature.
Genre un service d'impression ou des conneries de ce genre, t'as une seule imprimante et un seul service charge de la controler, sinon ca a pas de sens.
Et effectivement, c'est rare, voire carrement pas courant.
A la rigueur, ca peut se faire sur un service locator, tant que le service locator voit ses dependances injectees correctement.
Et donc paf la transition, 99% des usages de singleton (genre les factory a la mord moi le noeud de l'epoque doree des abus de design pattern au debut des annees 2000), le singleton je disais donc, est 99% du temps tres avantageusement remplace par un injection de dependance, connue sous le petit nom de ioc.
Spring etant l'implementation la plus repandue dans le monde java.
Et malheureusement, certains langage n'ont pas ce luxe, et abusent du singleton, parce que c'est encore ce qu'on fait de plus simple quand on a pas d'ioc.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Postgresql
Posté par Matthieu . Évalué à 6.
j'suis toujours sérieux.
Seulement sur ce site, je vois beaucoup de commentaires sur Java du genre "ils codent comme cela, c'est des gorets" sans arguments. Alors moi je veux bien essayer de comprendre et quitte à améliorer ma façon de coder, mais sans arguments, je ne comprends pas.
La sessionFactory est pour moi unique par sa nature, C'est ce qu'elle retourne qui peut ne pas être unique.
[^] # Re: Postgresql
Posté par pasScott pasForstall . Évalué à -2.
La session factory a rien d'unique, il se trouve juste que la plupart du temps, t'en as une seule, mais on peut tres bien imaginer une appli qui se connecte a deux sources differentes.
Ou par exemple, une db embarquee pour les tests unitaires et une vraie pour la prod.
Ton singleton va pas t'aider la.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Postgresql
Posté par Matthieu . Évalué à 0.
mouais... j'suis plutôt dans spring et les sessions HTTP...
toi t'es dans les bases de données et les sessions db. non ?
[^] # Re: Postgresql
Posté par pasScott pasForstall . Évalué à -3.
Gne?
Si tu veux tout savoir, je suis dans iOS, avec une grosse dose de spring cote serveur et tout plein de tests unitaires. Et pas de bases de donnees (meme si j'ai bouffe ma dose d'hibernate), du coherence et du solr a gogo, et surement du mongo a l'avenir.
Mais je vois pas ce que ca change au probleme.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Postgresql
Posté par Matthieu . Évalué à 1.
je voulais dire que toi tu parlais des sessions à la base de données, alors que moi j'avais en temps les sessions HTTP. ça change peut-être les choses.
[^] # Re: Postgresql
Posté par pasScott pasForstall . Évalué à -2.
Heuuu....
Tu crees les session http a travers une factory? En java?
Serieux?!?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Postgresql
Posté par Matthieu . Évalué à 1.
non, je crée un objet avec une factory qui contient des informations sur l'utilisateur connecté. Histoire de ne pas avoir à rechercher tout le temps son nom ou prénom dans ldap ou db.
Et je stocke cet objet dans la session.
[^] # Re: Postgresql
Posté par barmic . Évalué à -1.
Le singleton c'est ni plus ni moins qu'un cas particulier d'une factory.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Postgresql
Posté par guppy . Évalué à 0.
Le singleton c'est ni plus ni moins qu'un cas particulier d'une factory.
Peut-être que j'ai mal compris ou que tu t'es mal exprimé, mais :
Un singleton c'est une classe dont il ne peut exister qu'une seule instance
Une factory (fabrique en français), c'est une classe qui a pour responsabilité de créer des objets d'un certain type de base.
Même si il arrive souvent de rencontrer des classes qui sont à la fois des fabriques et des singletons, ton affirmation est clairement fausse.
[^] # Re: Postgresql
Posté par pasScott pasForstall . Évalué à 1.
Pas trop non, le but de la factory, c'est de te retourner différentes implémentations d'une meme interface, en fonction des paramètre de la méthode appelée. Elle peut, ou pas, s'assurer que t'as pas plus d'une seule instance d'une certaine classe, mais c'est ça reste un detail d'implémentation ca.
Le but du singleton, c'est de garantir que t'as une seule instance d'une classe donnée.
Ton getInstance() ne prend pas de paramètre, et n'est jamais censé de te retourner une implémentation différente d'une interface.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Postgresql
Posté par Matthieu . Évalué à 2.
heu, toujours pas compris.... et j'essayes de faire des efforts. Mais sans argument, je ne comprends pas.
La sessionFactory va te permet de récupérer un objet Session neutre. Les conditions initiales sont toujours les mêmes. Peux-être que tu peux récupérer des Sessions quelque peu différent en utilisant des paramètres (genre l'identifiant en paramètre). Mais je ne vois pas en quoi ça gène les tests. Le singleton n'est utilisable que s'il ne garde rien en mémoire. ça peut être le cas pour fabriquer des sessions.
[^] # Re: Postgresql
Posté par pasScott pasForstall . Évalué à -1.
Le probleme, c'est pas la session factory, c'est le singleton qui te la retourne. Lui il va la configurer d'une certaine facon, et c'est dans le code, donc pas modifiable.
Si tu veux lancer tes test unitaires contre une instance embedee de derby, tu vas avoir l'air malin avec ton singleton qui te retourne une factory configuree pour ton oracle en prod.
Si tu veux scinder ta db en 2 schemas distincts, tu vas maintenant devoir aller dans toute tes classes et changer tes appels au singleton par un autre singleton.
Ou alors tu parles des singleton beans de spring, mais c'est un abus de langage, par oppositiom au prototype bean, et ca a pas grand chose a voir avec le design pattern.
Et je comprends pas ton histoire de parametres, un singleton, par nature, ca prend pas de parametre.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Postgresql
Posté par Matthieu . Évalué à 1.
je parles des singletons spring
Pour le paramètre :
Session ma session = sessionFactory.getInstance().createSession("moi");
[^] # Re: Postgresql
Posté par pasScott pasForstall . Évalué à -2.
Alors, la tu me perds.
sessionFactory.getInstance()?
Ou SessionFactory.getInstnce()?
Parce que si t'as une instance d'un spring bean, pourquoi diable appeler get instance dessus?
Pour ton parametre "moi", comment tu fais pour le faire pointer sur ta db derby embarquee quand tu fais des tests unitaires?
Et note que le parametre s'applique a la factory, pas au singleton qui te retourne ladite factory.
Et comme dit plus haut, les singleton spring n'ont rien a voir avec le singleton pattern.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Postgresql
Posté par Matthieu . Évalué à 0.
non c'était bien SessionFactory.getInstance();
mais le SessionFactory ne pointe pas sur une DB. Il se contente de créer un object.
SessionFactory.getInstance().creerSession("moi");
Session creerSession(String qui){
Session s = new Session();
s.setQui(qui);
return s;
}
pour faire simple.
[^] # Re: Postgresql
Posté par pasScott pasForstall . Évalué à -2.
Et donc que fait spring la dedans? T'as pas d'ioc la dedans.
Ou alors t'utilises une factory method pour l'instancier?
Et last but not least: quand tu veux faire des test unitaires, comment tu changes la valeur de "moi"?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Postgresql
Posté par Matthieu . Évalué à -1.
là non effectivement, je n'ai pas spring dedans. Je gère le singleton comme dans le pattern.
Et la valeur de "moi" est changée ailleurs, je ne fais pas getSession("moi") mais getSession(toilabas.donneMoiLidentiant());
en général chez moi, le toilabas, c'est le client CAS. Mais on peut changer l'injection par spring pendant les tests parce que faire des tests unitaires avec CAS, c'est pas très simple...
[^] # Re: Postgresql
Posté par pasScott pasForstall . Évalué à -2.
Sinon, le fond du truc, c'est justement de pas faire ca. C'est la pire des choses que tu puisses faire, tu t'enfermes dans une implementation avec une config.
Public class MyRepository {
@Autowired
Private SessionFactory factory;
}
Un contexte pour tes tests unitaires, tu fais pointer ca ou tu veux.
Un contexte pour la prod.
Tu scindes ton schema de db? A branler, ca marchera pareil, a la rigueur il faudra que tu qualifies ton bean.
Et dans le meme ordre idee:
Public class MyService{
@Transactional
Public HTTPResponse truc(){
// foo
}
}
Une appli web va generalement vouloir une transactionalite au niveau de la requete HTTP, ca te permet de faire un rollback proprement si ta requete se banane.
Encore un autre avantage de pas utilise de singleton, ca permet a spring de creer un proxy qui va gerer les transactions pour toi.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Postgresql
Posté par barmic . Évalué à 1.
À quoi sert le singleton là dedans ? Pour quoi ne pas faire un simple :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Postgresql
Posté par Matthieu . Évalué à 1.
parce que la SessionFactory peut garder une connection à une base de données ou un ldap pour récupérer quelques informations sur "moi".
Cette connexion peut être partagée entre tous les processus vu qu'elle n'a rien de confidentielle/spécifique, c'est juste une interrogation d'annuaire.
Sinon oui, si la factory ne contient rien, un appel static fait l'affaire.
[^] # Re: Postgresql
Posté par pasScott pasForstall . Évalué à 9.
Parce que quand tu passes le delegate a ton prototype bean, t'as le controller qui va merger avec la view, le modele va alors interferer avec ton visitor pattern, ton flyweight explose en plein vol, le decorator se melange les pinceaux avec le grandfather code gen pattern et resultat, ton service locator ne locate plus rien.
J'veux dire, c'est completement glucose comme concept.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Postgresql
Posté par Marotte ⛧ . Évalué à -1.
Foutaise !
# Take your responsabilities, shut up and code !
Posté par GeneralZod . Évalué à 10.
Ce problème a été mentionné par Colin Charles (employé de Monty Programs et auparavant par MySQL AB) lors de l'Open World Forum le week-end dernier et c'est effectivement un vrai problème.
Monty est en partie responsable de cette situation (il a choisi le modèle double-licence, il a vendu en toute connaissance de cause MySQL à Sun sans aucune garantie), donc au lieu de passer son temps à se plaindre, il ferait mieux d'agir. Il serait grand temps que MariaDB devienne un vrai fork de MySQL et arrête de jouer au jeu du chat et de la souris avec Oracle. Soit Oracle est un partenaire correct et on travaille avec lui, soit il ne l'est pas et on se casse définitivement (merci la GPL).
C'est une nouvelle neuve que de savoir qu'Oracle c'est gros vilains méchants pas beaux et qui sentent mauvais. Monty c'est guère mieux, c'est grippe-sou qui se plaint qu'on ne lui rende pas la pleine propriété de son bien sans contrepartie après l'avoir vendu au prix fort.
[^] # Re: Take your responsabilities, shut up and code !
Posté par Maclag . Évalué à 4.
Ben en l'occurrence, on parle de lui, et je sens qu'il va bientôt sortir une grosse affiche "MariaDB, c'est aussi bien que MySQL avec tous les modules libres!"
[^] # Re: Take your responsabilities, shut up and code !
Posté par Albert_ . Évalué à 4.
Il y a aussi un autre fork a regarder et qui semble plus actif que MariaDB: drizzle.
[^] # Re: Take your responsabilities, shut up and code !
Posté par GeneralZod . Évalué à 5.
drizzle ne réponds pas aux même cahier des charges, il est optimisé pour la mise à l'échelle et les performances (d'où l'abandon de la couche moteurs de stockage), il supporte moins de types, pas de support du FTS (enfin, le support n'était pas non plus extra dans MySQL ou MariaDB), il utilise un nouveau protocole basé sur Google Protocol Buffers et n'est donc pas compatible avec les clients existants etc ...
MariaDB est un remplacement "drop-in" à MySQL (ce qui n'est pas sans poser de problèmes pour les distributions, du fait que les fichiers sont nommés de façon identiques), ça juste marche.
# Actian
Posté par vida18 . Évalué à 1.
On parle souvent de MySQL et de PostgreSQL mais jamais d'Actian (ex Ingres).
[^] # Re: Actian
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Ça ne me surprend pas : ça a été libéré pour bénéficier de l'effet de mode, mais sans conséquences puisque le successeur de Ingres PostgreSQL est déjà libre et attire déjà les contributeurs potentiels, je pense.
Par ailleurs, l'orientation actuelle de Ingres me fait surtout penser à un concours de Business Loto…
[^] # Re: Actian
Posté par Frank-N-Furter . Évalué à 5.
Et trop rarement de Firebird.
Depending on the time of day, the French go either way.
# SQLite
Posté par GNU_Eths . Évalué à 1.
Et SQLite alors, on peut très bien s'en servir pour remplacer MySQL.
Es ce que je me trompe ?
[^] # Re: SQLite
Posté par GeneralZod . Évalué à 8.
C'est pas les mêmes cas d'utilisation, SQLite est une base de donnée embarquée alors que MySQL est un serveur de base de données.
SQLite est certes très simple à utiliser, et est extrêmement avantageux dans bon nombre de cas (base embarquée, prototypage etc ...), mais ne gère absolument la concurrence, ne passe pas à l'échelle (à partir d'un giga de données, il est futile de continuer à utiliser SQLite), ne gère pas les utilisateurs.
[^] # Re: SQLite
Posté par barmic . Évalué à 5.
Il a aussi une gestion des types très particulière.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: SQLite
Posté par GNU_Eths . Évalué à 1.
En quoi ? Pourrait tu me donner un exemple contrait ?
[^] # Re: SQLite
Posté par windu.2b . Évalué à 3.
s/contrait/concret/
(ou alors, j'ai vraiment pas compris le sens de ta phrase...)
[^] # Re: SQLite
Posté par GNU_Eths . Évalué à 0.
Désolé, faute de frappe...
[^] # Re: SQLite
Posté par Joris Dedieu (site web personnel) . Évalué à 6.
sqlite> create table titi (
...> dutexte varchar(5)
...> );
sqlite> insert into titi values ("azertyuiop");
sqlite> select * from titi;
azertyuiop
[^] # Re: SQLite
Posté par GNU_Eths . Évalué à 1.
Ah oui, en effet.
C'est même expliqué sur la FAQ: http://www.sqlite.org/faq.html#q9
[^] # Re: SQLite
Posté par nud . Évalué à 1.
Resistance is futile
[^] # Re: SQLite
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 7.
sur un site perso qui a 3 visiteurs par jour, pourquoi pas.
Sur un "vrai" site, qui commence à avoir plusieurs hits simultanée, certainement pas. Sqlite, ce n'est absolument pas adapté pour faire du site web.
[^] # Re: SQLite
Posté par Niniryoku . Évalué à 2.
MySQL l'a été un jour ?
hop hop hop, je crois que c'est par ici, j'y cours ---->[¤]
Knowing the syntax of Java does not make someone a software engineer.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.