developer.jelix.org n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.
#376 closed bug (fixed)
saveControlToDao et requête surprenante
Reported by: | chris | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | Jelix 1.0 RC1 |
Component: | jelix:dao | Version: | 1.0 beta 3.1 |
Severity: | major | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Documentation needed: | ||
Hosting Provider: | Php version: |
Description
J'ai l'impression que c'est un bug, sans en être totalement sûr non plus.
Quand j'utilise saveControlToDao, il me génère une erreur, avec une requete pour le moins bizarre :
[error 403] Erreur dans la requête (Champ 'article_lieu.article_ART_id' inconnu dans where clause(DELETE FROM TJ_article_lieulivr_ARL WHERE article_lieu.article_ART_id = 1))
Le article_lieu étant l'attribut name de la primarytable de ma dao. Il est utilisé pour les champs alors qu'il n'y a pas d'alias sur le nom de table (realname), et pour cause.
Je doute que ce soit la méthode deleteBy() qui soit bugguée, ce serait donc (notez le conditionnel de réserve) le saveControlToDao, même si ça me laisse perplexe.
Change History (4)
comment:1 follow-up: ↓ 2 Changed 13 years ago by laurentj
- Component changed from jelix:forms to jelix:dao
comment:2 in reply to: ↑ 1 Changed 13 years ago by chris
Replying to laurentj:
ce serait bien d'avoir un aperçu de la dao, parce que là... je pense que c'est pas dans le where l'erreur mais dans le FROM. Si article_lieu est le nom de la table, pourquoi y a ce TJ_article_lieulivr_ARL ?
Comme je l'ai dit, article_lieu c'est le name de la primarytable, alors que le realname est TJ_article_lieulivr_ARL
<datasources> <primarytable name="article_lieu" realname="TJ_article_lieulivr_ARL" primarykey="article_ART_id lieu_LIV_id" /> </datasources> <record> <property name="article" fieldname="article_ART_id" datatype="int" required="yes"/> <property name="code" fieldname="lieu_LIV_id" datatype="int" required="yes"/> </record>
Pour info, pour pouvoir continuer à avancer, j'ai du désactiver le deleteBy :
--- lib/jelix/forms/jFormsBase.class.php.orig 2007-12-13 13:59:45.000000000 -0400 +++ lib/jelix/forms/jFormsBase.class.php 2007-12-13 13:59:55.000000000 -0400 @@ -381,7 +381,7 @@ $daorec->{$pkNamelist[$k]} = $pk; } - $dao->deleteBy($conditions); + //$dao->deleteBy($conditions); $valuefield = $pkNamelist[$k+1]; foreach($values as $value){
et le traiter à la main :
$artlieuFactory = jDao::get('public~article_lieulivr'); $conditions = jDao::createConditions(); $artlieuFactory->deleteByArticle($id);
avec :
<method name="deleteByArticle" type="delete"> <parameter name="article" /> <conditions> <eq property="article" expr="$article" /> </conditions> </method>
comment:3 Changed 13 years ago by laurentj
- Resolution set to fixed
- Status changed from new to closed
Ok merci pour les précisions. Il s'agit donc bien d'un bug dans jDaoFactoryBase::_generateCondition.
Bug corrigé dans le trunk.
comment:4 Changed 13 years ago by chris
Parfait, merci à toi.
ce serait bien d'avoir un aperçu de la dao, parce que là... je pense que c'est pas dans le where l'erreur mais dans le FROM. Si article_lieu est le nom de la table, pourquoi y a ce TJ_article_lieulivr_ARL ?