Discussion :

[Invité]

Bonjour,

je rencontre de nombreux problèmes avec les connecteurs natifs sur une base mySQL hébergée. Initialement un moteur myISAM suffisait mais il devrait être remplacé par un innoDB dans la prochaine version. Le programme a été développé en Lazarus, il y a 2 ans maintenant et je dois le réactualiser. Il fonctionne sous Win, Nux et un Mac

1. Avec les connecteurs natifs, sous innoDB, il semble que le verrouillage des lignes fonctionnent mal enfin plus exactement leur déverrouillage. Je bloque une ligne de la table (en transactionnel Autocommit = 0 + serializable) sur un serveur 5.0.90 par une requête genre
   
   • SELECT usNOM FROM taUsers WHERE usID = :pausID FOR UPDATE;
   
   et débloque par un
   
   • UPDATE taUsers SET usNOM = :paNOM WHERE usID = :pausID;
   
   en prenant les précautions d'usages avec les commit et rollback de rigueur.
   
   Je viens d'installer Zeos7. Un code équivalent à celui utilisé pour les connecteurs natifs fonctionne correctement. Mais avec ces derniers, je n'arrive pas à déverrouiller sauf à déconnecter le MySQL50Conn. Il y a une particularité à connaître ?
   
   
2. Autre problème : la connexion n'est pas persistante. Je n'ai pas le moyen "direct" de rendre la connexion persistante puisque l'hébergeur ne me permettra pas de modifier le paramètre connect_timeout du serveur mutualisé. Il n'y a pas de ping comme avec Zeos. Donc, régulièrement un thread exécute une requête simple pour maintenir la persistance. Or si ce thread s'effectue en même temps qu'une requête est lancée par l'utilisateur du programme, ce dernier plante. Le problème m'avait été signalé mais il est très peu fréquent et à l'époque, j'ai bien identifié le problème mais sans trouver de solution. Mais peut-être ai-je mal cherché ?
   
   
3. Enfin avec les connecteurs natifs comme avec Zeos, je ne sais pas s'il existe un moyen de réduire le temps d'attente (sur ma base 60 s) pour être informé que l'enregistrement est bloqué : avec pgSQL, je dispose d'un FOR UPDATE NOWAIT inconnu par mySQL. Or dans l'attente de ce message, le programme "freeze". Impossible de bouger la Form... Un thread me semble mal habile pour régler ce genre de problème.

Question complémentaire : les Zeos7 fonctionnent-ils sous Mac OSX ? J''avais choisi à l'époque les connecteurs natifs à cause d'une certaine susceptibilité à l'installation des Zeos.

Bref, je cherche une solution économique en temps pour que cela fonctionne proprement. Plusieurs solutions :

• Remplacer les connecteurs natifs par des Zeos à condition qu'ils soient compatibles Mac. J'imagine la tête de mon collègue si je lui annonce que cela n'est plus disponible pour son OS préféré
• Utiliser pgSQL (le "freeze" n'est pas acceptable) mais le Front Office est en php... Cela va être pénible.

Si tel n'est pas le cas (économie de temps), je bascule vers mon autre plate-forme de développement... Ce sera plus long mais très enrichissant... et donc le temps dans ce cas est moins important. En réalité, je cherche à gagner du temps pour en accorder à l'autre plateforme.

Merci.
Cordialement. Gilles

[Gouyon]

Si tu cherche a basculer sur un autre environement de développement je suggère Java. Mais énorme travail en perspective .

En ce qui concerne Zéos sur mac je serais toi je ferais déjà un petit essai avec une base toute simple. Avec au programme

1. Réalisation d'une connection
2. lectures de tables
3. exécutions de requêtes

Ça devrait couvrir une grosse partie de tes besoins

Utilise un mutex dans ton thread. Lorsque le thread s’exécute pour maintenir la connexion il interdit toute activité sur la base et dès qu'il a fini il autorise de nouveau l'accès. De cette façon si l'utilisateur lance une requête il est bloqué et dès que le thread rend la connexion la requête s'exécute. Il faudrait faire de même pour chaque requête.

[tintinux]

Bonjour

Pourquoi pas Zeos 6 ?
Il marche parfaitement, y compris pour les locks et sans besoin de thread.

J'ai pas essayé sur Mac, mais je crois que c'est bon aussi.

Par contre pour le 64 bits, je crois que c'est mort... mais pas si sûr.

[Invité]

Bonjour,

Merci à tous deux pour vos réponses.

A Rémi : je n'ai un Mac que de manière épisodique, quand je l'emprunte à l'un de mes lycéens, mon collègue ayant trop peur que je déglingue son bel appareil. Et en ce moment -pendant les vacances- je n'en dispose pas.

En effet le mouvement est largement entamé depuis plusieurs mois, ce qui explique ma moindre participation à ce forum : j'abandonne petit à petit Lazarus pour Java.

Pour le client riche, c'est bon. Je ne me débrouille pas aussi naturellement qu'avec Delphi7/Lazarus mais je dois reconnaître que c'est très bien foutu... et productif... et performant. J'avais testé, il y a 2 ans cette plateforme en même temps que C++... et j'étais retourné finalement à Lazarus. Mais ce dernier ne progresse pas comme je l'attends (l'attendais). Donc, j'ai redécouvert le langage (et les IDE) avec lesquels j'avais le plus d'affinité lors de mes tests il y a 2 ans. C'est curieux parce que de prime abord, ayant utilisé C++ Builder (le 6 je crois), j'aurais parié initialement pour le C++. Les contraintes de QT l'éloignent trop de ma partique...

Mais, pour l'approche internet avec Java, là j'avoue, la tuyauterie est revêche. Intellectuellement, à mon avis, c'est passer à côté de beaucoup de choses intéressantes que de rester en PHP alors qu'on utilise "déjà" Java... même si mes sites n'ont pas un volume qui justifie l'emploi de Java en production.

Or investir dans autre chose que Lazarus devient chaque jour une nécessité. C'est au minimum un problème de confiance. J'ai essayé XE2. FMX n'est pas abouti. La doc est digne de celle de Lazarus. Pas de date pour le portage Linux. Beaucoup d'habitudes ne sont plus delphiennes ni lazarusiennes. C'est vraiment un autre produit.. et en même temps c'est le même. J'y perds mon latin avec mes vieux "réflexes VCL transcendés par l'usage intensif de la LCL". Je ne le condamne pas avant qu'il ait atteint sa quintessence. Mais sans doc c'est vraiment agaçant et même insupportable avec des points de repère non transférables. De plus, je suis un peu échaudé par les promesses de lendemains sensationnels : je cherche une plateforme stable et efficace actuellement.

Quant au Mutex, avec Lazarus c'est tout une histoire dont ici une petite discussion savoureuse (au bout du 5ème ou 6ème échange) sans rapport direct... mais je me suis "pris la tête"il y a quelques mois avec une chaine Connecteur-->dbGrid que je voulais threader (en 2 threads successifs) pour fluidifier le remplissage d'un grand volume... Jamais réussi, j'ai réglé ce problème avec Connecteur+Query+StringGrid.

A Tintinux : En Lazarus, j'ai un nouveau problème. Cette requête passe en "natif" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
SQL.Add('SELECT vrVERSION FROM taVers WHERE (vrLOGICIEL = :paLOGICIEL) AND (vrOS LIKE :paOS);');
      with Params do begin
      ParamByName('paLOGICIEL').AsString := StrToSQL(uppercase(FexeName), gsLICprotocol);
      {$IFDEF windows}
       ParamByName('paOS').Value := StrToSQL('%win%', gsLICprotocol);
      {$ELSE}
       {$IFDEF linux}
        ParamByName('paOS'.Value := StrToSQL('%lin%', gsLICprotocol);
       {$ELSE}
        {$IFDEF Darwin}
          ParamByName('paOS').Value := StrToSQL('%mac%', gsLICprotocol);
        {$ELSE}    [...]

Le StrToSQL est une fonction pour régler les problèmes d'encodage de la requête elle-même en fonction de l'OS notamment les "%" parce que sous Win (tjs pas natif en utf8) et Lin (qui l'est depuis longtemps) cela complique un peu le traitement ... Mais là, Lazarus n'y est pas pour grand chose.

La même requête sous Zeos7 plante Lazarus. J'ai regardé le fonctionnement d'un ttLIKE. Pas de doc comme d'hab... Bref on passe comment une requête par injection contenant un like % % sous Win et Nux avec Zeos ?

Zeos 6.6 stable oui mais faut-il encore le patcher pour l'installer sur les SVN Lazarus et FPC ? On peut appeler cela stable en effet.

Très dommage parce que l'équipe de Zeos court désespérément après les évolutions de Lazarus/Fpc. En même temps, ils doivent s'adapter à Delphi qui bouge pas mal aussi. Je comprends bien que Lazarus soit soumis aux évolutions des environnements gtk3, windows8, androïd ?... J'ai demandé pourquoi "ils" ne prenaient pas le temps de faire les adaptations minimales, quitte à prendre un peu de retard... et par les moyens libérés, d'engager une stabilisation maximale et de rédiger une documentation à ce moment. Pas facile de rédiger une doc efficace alors que les méthodes des composants et bibliothèques ne sont jamais stabilisées. J'avais fait la même demande, il y a deux ans quand j'avais rencontré ce problème. La réponse est inchangée : cette conception du développement -avec des phases de stabilisation- est archaïque. Tout doit s'adapter en même temps et parallèlement... et je subodore même qu'il ne leur soit plus possible de le faire, tellement le code est instable est "sur-surcouché" et entrelacé de manière inextricable. Ce qui explique pourquoi chez Lazarus, les versions dites stables sont toujours aussi buggées (ou presque autant que celles qui ne sont pas dénommées ainsi). C'est vrai que courir après Ubuntu... Je suis un adapte de Debian... alors la rustinisation généralisée, l'adaptation permanente sans pause (ni feedback) C'est peut-être bon pour le commerce, mais Lazarus n'appartient à ce type de circuit de disbribution... Bref, un jour un bug est signalé. Réparé par X quand il a fini le bout de code sans rapport... qu'il adaptait. Rebousillé par l'adaptation parallèle ou entre temps de Y (un ancêtre par exemple). Resignalé... Que de perte de temps et de moyens.

Cordialement. Gilles

[Invité]

Les 2 problèmes sont résolus avec Zeos....

Mais pour cela :

1. J'ai installé le dernier snapshot de Lazarus/FPC : Lazarus-1.1-37902-fpc-2.6.1-20120709-win32.exe
   Erreur au lancement : le dossier du FPC Sources est mal paramétré.
   
   • dans la vieille 1.1-37477-fpc-2.6.1-20120602, il est dans fpc/2.61/source
   • dans la nouvelle 1.1-37902-fpc-2.6.1-20120709, il est dans fpc/source
   
   Ce n'est pas grave mais lors du changement de structure des dossiers, l'Equipe aurait pu modifier les paramètres par défaut de configuration... Y a celui qui change la place du répertoire dans l'arborescence, un autre doit changer les paramètres de configuration... J'avais oublié, les Mutex sont un peu buggués en Lazarus... même si preuve à l'appui, il paraît que non parce que c'est l'utilisateur qui ne sait pas programmer. J'ai connu cela avec les StringGrids. Malheureusement, on trouve plein de ce genre de réflexions de "bidouilleurs géniaux" inféodés dans le forum officiel et parfois même dans le bug tracker. Le mutex dans l'Equipe, cela doit être l'explication... à moins que l'erreur soit volontaire : c'est plus "fun". A l'autre bout de la chaîne, il y a le gars qui installe Lazarus et qui commence, à la première ouverture, par un message d'erreur bloquant. Encore là c'est sympa, c'est la version Windows...
2. J'ai téléchargé la ZEOSDBO-6.6.6-stable.zip
   Ininstallable - Bug répertorié
3. J'ai chargé la dernière SVN de la 6
   Installable.
   Je teste avec un malheureux SELECT : "Classe d'exception EZSQL : Zeos6\src\dbc\ZDbcMySqlUtils.pas line 392 --> Table 'Database.t' doesn't exist" : Tu m'étonnes ! La table s'appelle taVersions mais quel que soit le nom, il n'en prend que la première lettre... Ben voyons
4. Désinstallation de la SVN Zeos 6 et nettoyage par Clean et Rebuild de la version de Lazarus installée
5. Installation de la SVN Zeos 7 : OK. Tiens les icônes n'ont pas changé ? Hum...
6. J'efface le répertoire de Lazarus et rebaptise la copie que j'en avais faite avant d'installer Zeos 6
7. Ré-installation de la SVN Zeos 7
   Miracle : les verrous fonctionnent (il n'y avait pas de prob avec Zeos) et aussi
   

   Code :

   Sélectionner tout - Visualiser dans une fenêtre à part

   1
   2
   3
   4
   5
   6
   7
   8
   with SQL do begin
         Clear;
         Add('SELECT vrVERSION FROM taVersions WHERE (vrLOGICIEL = :paLOGICIEL) AND (vrOS LIKE :paOS);');
         with Params do begin
           ParamByName('paLOGICIEL').AsString := 'TEST';
           ParamByName('paOS').Value           := '%win%';
         end;  
   [..]

Donc sans rien changer au code initial. il suffisait de prendre la release du jour de Lazarus/FPC et d'y installer la trunk de Zeos 7. Normal !?
C'est une immense farce... Je fulmine.

Bon peut-être qu'il est possible de verrouiller avec les composants natifs sachant que contrairement à Zeos, le LIKE avec injection fonctionne "nativement" ? J'attends la release de demain ou je perds encore une journée ?

En résumé, j'ai une solution qui fonctionne sans certitude sous Mac, probablement pas en 64 bits quelque soit l'OS et une qui potentiellement fonctionne dans tous les environnements mais n'applique pas les codes de verrouillage usuels... et qui ne sait pas gérer les problèmes de persistance des connexions...

Je sens que cela progresse... Encore 2 ou 3 jours et je devrais y arriver. Lazarus permet bien de développer sous Win/Lin et Mac sous 32 et 64 bits ?
Bonne journée. Gilles

[Invité]

Bon finalement, j'ai un code qui peut convenir avec les connecteurs natifs. Le problème avec les verrous sur mySQL a été référencé en 2007. Une petite évolution en 2009 : http://lazarus.freepascal.org/index.php?topic=12750.0

Et depuis rien... En tous cas, je n'ai rien trouvé. J'admets de moins en moins ce genre de bugs, leur non-traitement, la diffusion "confidentielle" de ces "no problems" et le rustinage ruineux en temps nécessaire au niveau du projet en cours de développement. D'autant que le code du projet est inutilement compliqué. Impossible de le reformater facilement par exemple pour basculer vers Zeos... en cas de nouvelles découvertes. Je ne sais même pas si les exceptions nécessaires sont efficaces dans tous les cas de figures. Bref de la bidouille...

Reste le problème de la persistance avec les connecteurs natifs...

Ajout : 11/07/12 - 16:20 : la solution avec les connecteurs natifs ne semble plus poser de problème avec la persistance. C'est géré automatiquement ?

Cordialement. Gilles