developer.jelix.org is not used any more and exists only for history. Post new tickets on the Github account.
developer.jelix.org n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.

Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#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: Changed 13 years ago by laurentj

  • Component changed from jelix:forms to jelix:dao

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 ?

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.

Note: See TracTickets for help on using tickets.