Piwigo Bugtracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000397Piwigosynchronizationpublic2006.06.02 10:572006.07.04 00:51
ReporterjuSt 
Assigned Toplg 
PrioritynormalSeverityblockReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version1.6.0RC1 
Target VersionFixed in Version1.6.0RC3 
Summary0000397: Column 'uploadable' cannot be null
DescriptionJ'ai ce problème lorsque je tente de synchroniser mon espace free avec celui de plebia. Quand je simule ça passe, quand je décoche simuler voici ce que ça met :


INSERT INTO phpwebgallery_categories
  (id,dir,name,site_id,id_uppercat,uppercats,commentable,uploadable,visible,status,rank,global_rank)
   VALUES
  ('13','amis','amis','2',NULL,'13','true',NULL,'true','public','3','3')
;
[mysql error 1048] Column 'uploadable' cannot be null
TagsNo tags attached.
browserMozilla
Database engine and version
PHP version
Web serverApache 1.3.x
Attached Files

- Relationships

-  Notes
(0000997)
plg (manager)
2006.06.02 22:30

Après une bonne demi-heure de recherche, je pense avoir trouvé le problème, c'est une histoire de type de variable et de mode de comparaison je pense. Peux-tu faire le test suivant : dans admin/include/functions.php, ligne 611 remplace

if (!isset($insert[$dbfield]) or $insert[$dbfield] == '')

par

if (!isset($insert[$dbfield]) or $insert[$dbfield] === '')

(un simple signe "=" à ajouter) et me dire si ça corrige bien le problème ?
(0001002)
juSt (reporter)
2006.06.02 23:16

Ca marche !

Merci !
(0001005)
plg (manager)
2006.06.02 23:46

Je reste encore sur un sentiment amer d'incompréhension. En effet, dans admin/site_update.php, on passe une chaîne de caractère pour le champ "uploadable" et pas un booléen. Dans mes tests en local, j'ai simulé le site distant et cela fonctionne très bien.

Bref, j'attends encore un peu avant de commiter la modification que tu as testé avec succès.
(0001014)
mathiasm (manager)
2006.06.03 23:42

est-ce que ça peut venir de ce comportement: http://fr2.php.net/manual/fr/language.operators.comparison.php#43754 [^]

A priori, le double égal fait de la conversion de types.
(0001164)
plg (manager)
2006.07.04 00:51

- corrigé en branche 1.6 [Subversion] r1427
- reporté sur trunk [Subversion] r1428

J'ai donc pris la solution de l'opérateur "===", mais je ne comprends pas vraiment pourquoi c'est utile dans le cas présent.

- Issue History
Date Modified Username Field Change
2006.06.02 10:57 juSt New Issue
2006.06.02 10:57 juSt browser => Mozilla
2006.06.02 10:57 juSt Web server => Apache 1.3.x
2006.06.02 22:30 plg Note Added: 0000997
2006.06.02 22:30 plg Assigned To => plg
2006.06.02 22:30 plg Severity minor => block
2006.06.02 22:30 plg Status new => assigned
2006.06.02 22:30 plg Category upload management => directories update
2006.06.02 22:30 plg Platform on plebia.org =>
2006.06.02 22:37 plg Status assigned => feedback
2006.06.02 23:16 juSt Note Added: 0001002
2006.06.02 23:46 plg Note Added: 0001005
2006.06.02 23:48 plg Status feedback => assigned
2006.06.03 23:42 mathiasm Note Added: 0001014
2006.07.04 00:51 plg Note Added: 0001164
2006.07.04 00:51 plg Status assigned => closed
2006.07.04 00:51 plg Resolution open => fixed
2006.07.04 00:51 plg Fixed in Version => 1.6.0RC3


Copyright © 2000 - 2015 MantisBT Team
Contact
Powered by Mantis Bugtracker