AccueilCodesTutorielsForumsEmploiLivresGuide achatConnexion

  • CodeS-SourceS
  • RSS CodeS-SourceS
  • CodyxBot, le Bot GTalk & MSN qu'il vous faut !
  • Générez des revenus avec vos codes, scripts et tutoriaux
  • Aide à la navigation du site
begin process at 2009 07 11 10:26:28
Vous ne trouvez pas de réponse à votre problème ? Alors posez la question dans le forum. Souvenez-vous qu'il n'y a jamais de question bête, mais rester dans l'ignorance parce que l'on n'ose pas poser une question, ça c'est une erreur !

12 commentaire(s) de Dargos sur des sources sur tout CodeS-SourceS

Le : 27/03/2008 23:49:28
Source : DBMAP - AUTOGÉNÉRER DES REQUETTES MULTIBASES
salut, je viens de mettre à jour le zip avec la gestion des tables d'association.
j'ai aussi fourni le dump de la base de données de test (MySql).
pour repondre à vos questions, il est vrai que mon projet ressemble à link. d'ailleurs, j'etais bien degouté quand j'ai vu arriver link qui utilisait la meme technique que moi pour les attributs. la mecanique interne, je crois que c'est bien plus evolué que la mienne :p
sinon, oui, le but de ce projet est de ne plus faire de requettes. et meme mieux : le but est de pouvoir changer de sgbdr sans changer le code. changer les noms de tables ou de columns, en n'ayant qu'à modifier les attributs dans les classes de mapping.
autrement, le but de ce programme est d'avoir des objects "normaux", avec des collection d'objects... mais en sql, le schéma est obligatoirement différent (l'exemple avec les voitures) : on doit desfois passer par des tables d'associations.
j'ai l'habitude de devoir travailler sur des bases imposées (mal faites et souvent changeantes) donc mon prog a été pensé pour s'y addapter. si on veut générer les classes avec leurs attributs, il va falloir faire un autre projet et bien déterminer les besoins ;)
en tout cas, merci à vous pour ces commentaires !
j'en attend d'autres par rapport au support des tables d'association ;)
(il serait peut etre aussi utile de remplir des dictionnary<,> mais dans quel ca ? )

Le : 26/03/2008 19:07:03
Source : DBMAP - AUTOGÉNÉRER DES REQUETTES MULTIBASES
pour la question du "RealInsert", je pense que ce n'est pas à mon systeme de vérifier s'il existe ou pas une clef identique. par exemple, dernierement, j'ai eu une "DuplicatedKeyException", et j'etais bien content d'avoir cette exception justement. apres, c'est peut etre au programmeur de faire ces verification, ou meme des try{insert} catch{update} par exemple.
apres, pour les jointures, j'ai reussi à faire quelque chose de pas mal, mais je me pose encore la question des tables d'associations. je depose donc le nouveau zip.

Le : 25/03/2008 21:24:31
Source : DBMAP - AUTOGÉNÉRER DES REQUETTES MULTIBASES
Tmcuh, ce que tu dis par rapport aux "fields", ca me fait grandement penser à un simple DataRow. la raison pour laquelle je n'aime pas les DataRow, c'est qu'il faut connaitre le nom des propriétés en String, et donc à la compilation, on ne peut rien verifier. avec mon systeme, on ne gere que des propriétés donc vérifications à la compilation.
ensuite, si un jour, un champ de la base change, il suffit de modifier l'attribut de la propriété concernée, et rien d'autre ne changera dans le code ! (sauf si on utilisait le nom du champ au lieu d'utiliser des groupes) au fait, pour ca, j'ai aussi modifié le systeme, pour pouvoir donner les noms des propriétés de l'object au lieu de l'appeller par le nom du champ de la base (ce qui donnera des mauvais resultats si ce nom change change).
allez, bientot un update du zip, quand ca sera un peu plus propre pour les jointures ;)

Le : 25/03/2008 21:13:59
Source : DBMAP - AUTOGÉNÉRER DES REQUETTES MULTIBASES
salut salut,
ya d'la bonne idée, la ;)
bon, pour l'instant, j'ai reussi à faire des jointures, mais il faut encore que je rende ca plus maniable : dans nos classes, on a souvent une propriété qui est une liste d'objects, et bien, avec une simple ligne, ca genere la requette, et remplis les objects et listes d'objects. par exemple, dans la classe user, j'ai mis une propriété ville qui a un code postal et un nom. il y a une table equivalente dans la base de données, et quand je lance le programme, ca me remplis bien la ville. j'ai aussi fait le test avec une collection de voitures pour le user, et ca marche ausi. je me pause en ce moment des questions par rapport aux inner join et left join, mais je vais m'en sortir ;)
sinon, il est vrai que pour l'instant, on fait nos objects à la main, ce qui est bien mais pas top. pour ca on peut avoir plusieurs possibilités : regarder la base de données, et générer les classes à partir de ca. mais le probleme, je trouve, c'est que la plus part du temps, les objects et la base, c'est pas la meme architecture : exemple avec une table d'association que l'on a pas dans les objects : on fera juste une List<>. alors quelle est la meilleure solution ? peut etre proposer les deux ;)
ce qui serait idéal, ca serait peut etre de générer les objects à partir d'un xml. et au besoin générer le xml à partir de la base !
à débattre :)

Le : 21/03/2008 18:20:17
Source : DBMAP - AUTOGÉNÉRER DES REQUETTES MULTIBASES
effectivement, pour la puissance des procedures stockées. bien que les curseurs soient lents, ils sont quand meme plus rapides que plein de requettes pour faire la meme chose !
par contre, je peux quand meme faire en sorte de supporter les procédures stockées de maniere simple.
pour l'instant, je continue le programme vers le support des jointures. on verra plus tard pour les procedures stockées ;)
a l'heure actuelle, on peut les executer "a la main" avec mon systeme, c'est deja ca ;)

Le : 21/03/2008 17:54:43
Source : DBMAP - AUTOGÉNÉRER DES REQUETTES MULTIBASES
pour le coté PL SQL par exemple, avec mon systeme on va pouvoir le faire en faisant dans la classe OracleDbMap les override qu'il faut.
ensuite, pour les procedures stockées, au debut j'avais prevu ca, mais je l'ai enlevé car mal géré. mais maintenant, je peux le rajouter, ce sera facile (et mieux géré qu'au début :p )
ensuite, je me suis appliqué pour les perfs : toutes les requettes (gérées avec des iDataParameters) sont stockées et réutilisées au besoin, donc le gros calcul sera fait uniquement pour la premiere des requetes identiques.
aussi pour les perfs, il peut etre lent de faire le tour des GetProperties() d'un object et de recupérer son attribut à chaque requette. pour cela, j'ai géré une dictionary qui stoque les clefs PropertyInfo/DbColumnAttribute. donc c'est aussi amélioré.
alors apres, pour le coup des tables par classe, c'est vrai que c'est pas terrible. seulement, pour l'instant, c'est suffisant. mais effectivement, on va vite avoir desoin de jointures. justement, j'y reflechis. je pense mettre un parametre optionnel à DbColumnAttribute pour specifier la table jointe, avec les conditions de jointure. mais ca ne va pas etre si simple que ca. il faut encore que j'en definisse l'architecture. a voir donc ;)
et ausi, coté code, si certaines choses paraisent floues, n'hesitez pas à me demander :) c'est peut etre aussi que le code n'est pas assez clair, et c'est donc à coriger ;)
Dargos

Le : 20/03/2008 21:40:19
Source : DICTIONNAIRE OPTIMISE
exactement tmcuh.
en fait, quand on parle de dictionaire, c'est surtout avoir des paires clef/valeur (sinon on va plutot parler de liste).
donc à priori, il faudrait juste ajouter une valeur de type string sur les noeuds '\0'.
quand on va ajouter un mot, on l'ajoutera avec sa valeur : la methode ajouter_mot prendra donc 2 strings en parametre.
ensuite, vu de l'exterieur, on ne devrait pas avoir acces à la mecanique interne de la classe, mais n'avoir que 3 ou 4 methodes publiques comme ajouter, enlever, vider, charger_depuis_fichier. en particulier, on de devrait pas accéder à cette List<Noeud> particulierement dans la signature des methodes.
ensuite, dans le dictionaire, on va le plus souvent demander la valeur d'un mot, et une seule fois loader le dico complet. ce qui serait idéal serait d'avoir une public method qui renvoie une string valeur à partir d'une string clef.pour finir,
pour ca, il va falloir trouver quelle forme donner au fichier, vu qu'on rajoute des valeurs aux clefs : un xml, autres ?
Tmcuh, je suis bien d'accord avec toi pour dire qu'en vitesse acces, c'est surement la methode la plus efficace !
sinon, je vais encore coser un peu la chose :
peux tu predire ce qu'il va se passer si 2 threads ajoutent le meme mot au meme moment ?
si tu comptes laisser la methode ajouter_mot publique, il va surement falloir penser à la synchronisation des threads ! je te laisse y reflechir, mais tu peux te renseigner sur la classe ReaderWriterLock ;)
G33kemenT, Dargos

Le : 19/03/2008 19:10:10
Source : DICTIONNAIRE OPTIMISE
simple et efficace, j'aime bien :)
par contre, pour etre pointilleux, je dirais que la methode "ajouter_mot" a un probleme :
cette methode est recursive, et elle appelle à chaque fois la methode "existe_mot" recursive aussi. en modifiant de tres peu et en utilisant de preference la methode "est_dans_liste", ca serait surement plus efficace.
ensuite, je ne suis pas tres concerné pas les mots croisés, mais j'utilise souvent des dictionnary pour faire des traductions des textes de l'application. vu ce que tu viens de faire, j'imagine que tu vas proposer une bonne idée ;)

Le : 07/06/2007 16:35:56
Source : [.NET 2.0] - CLASSE POUR GÉRER FACILEMENT LES PREDICATE POUR LES GENERICS + CLASSE SERIALIZATION - DESERIALIZATION XML GENERIQUE
pour ton histoire de multitude de predicateHelper, tu devrais peut etre faire une classe generique genre
public class PredicateHelper<T>{}
ca t'eviterais de reecrire plusieurs fois la meme chose.
tu devrais peut etre implementer l'interface IComparable.. je sais pas..

sinon, pour les List<T>, dans la methode FindAll(predicate(T)) par exemple, tu peux utiliser une syntaxe comme ceci :
int valSup=10;
List<int> MyIntList = new List<int>();
foreach (int myInt in MyIntList.FindAll(delegate(int di) { return di > valSup; }))
{
     Console.WriteLine(myInt.ToString());
}

ce code va tout simplement te sortir les items de ta liste qui sont >10 sans avoir à créer une fonction qui ne servirait qu'une seule fois...

;)

Le : 07/09/2006 12:37:31
Source : THREADSAFE GENERIC SORTEDLIST
sashka_shurik :
>Tu peux implementer ton propre IEnumerator qui serait l'enfant de IEnumerator de C# et qui aurait tout le code necessaire pour la protection thread.
>la migration d'un class generique vers le tien(et vise versa) se ferrait facilement.

effectivement !
mais la, je ne sais comment faire : dans le foreach, il y a un appel au IEnumerator a chaque boucle. d'où le fait que je bloques au debut du foreach, et que je libere à la fin...
peux tu m'en dire plus sur ceci ? (implementer ton propre IEnumerator)
en tout cas merci pour ce bon commentaire :)



1


Nos sponsors

Sondage...

CalendriCode

Juillet 2009
LMMJVSD
  12345
6789101112
13141516171819
20212223242526
2728293031  

Consulter la suite du CalendriCode

Appels d'offres

Comparez les prix Nouvelle version


Console Nintendo DSi Blanche
Entre 160€ et 170€


Visiter le guide achat

Photothèque Nouveau !

Photo sitges beachPhoto femme, plage, bien être, soleil, vacances, été, détente, repos
Photo a pretty teenage girlPhoto femme, plage, bien être, soleil, vacances, été, détente, repos

Visiter la photothèque


Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés
Temps d'éxécution de la page : 0,234 sec

Google Coop CodeS-SourceS Google Coop CodeS-SourceS


Certaines images présentes sur le site (notament certains avatars) sont issues des collections IconShock, donc si vous souhaitez utiliser ces icons vous devez les acheter, ne les copiez pas et ne utilisez pas dans vos sites et applications sans les avoir commandé.