Discussion :

[clavier12AZQSWX]

bonjour,

localement j'ai une simple requête UPDATE sur une vue VIEW assez simple qui fonctionne alors que sur le serveur de prod, elle bloque avec le message :

The target table XXX of the UPDATE is not updatable (1288)

d'où peut venir le problème ?
config mysql ou version de mysql ?

En local de dev, j'ai cette version :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
in_predicate_conversion_threshold 	1000
innodb_version 	10.4.8
protocol_version 	10
slave_type_conversions 	
system_versioning_alter_history 	ERROR
system_versioning_asof 	DEFAULT
tls_version 	TLSv1.1,TLSv1.2,TLSv1.3
version 	10.4.8-MariaDB
version_comment 	mariadb.org binary distribution
version_compile_machine 	x64
version_compile_os 	Win64
version_malloc_library 	system
version_source_revision 	4c2464b87d58a43d1292e166bae6720b51f4b000
version_ssl_library 	WolfSSL 4.1.0

et en prod mutualisé j'ai cette version :

Code :

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

1
2
3
4
5
6
7
8
innodb_version 	5.7.32
protocol_version 	10
slave_type_conversions 	
tls_version 	TLSv1,TLSv1.1,TLSv1.2
version 	5.7.32-log
version_comment 	MySQL Community Server (GPL)
version_compile_machine 	x86_64
version_compile_os 	linux-glibc2.12

Ma requête de création de vue est assez simple (sans calucl de math) :

Code :

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

1
2
3
4
5
6
7
  CREATE OR REPLACE VIEW edt_cahier_pointages AS 
	SELECT point_id, point_visible, point_date_crea, point_date_mod, point_user_crea, point_user_mod, 
		point_edt_id, point_type_id, point_com_prof, point_etu_id, etu_photo
	FROM pointages
	LEFT JOIN etudiants ON point_etu_id=etu_id
	WHERE point_visible=1
	;

Du coup, une simple update d'un champs string ne devrait pas poser pas de souci :

Code :

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

update edt_cahier_pointages set point_com_prof='test' where point_id=12

et pourtant en prod j'ai l'erreur 1288

The target table edt_cahier_pointages of the UPDATE is not updatable

D'où cela peut bien provenir ?

[al1_24]

Je ne suis pas certain que la version 5.7 de MySQL de 2015 prenne en charge les mises à jour de vues.
Il est préférable d'effectuer ses développements dans le même environnement logiciel que la production pour éviter ce genre de déconvenue. (Ou au minimum avoir un environnement de recette comparable à la production)

[clavier12AZQSWX]

merci al1_24 pour votre réponse.
entre temps, j'ai trouvé la cause (mais pas la solution).

Dans la version prod, les VIEW update ne fonctionnent pas quand elles sont construites avec les option "LEFT JOIN" !
Ainsi, dans ma vue je l'utilise hélas :

CREATE OR REPLACE VIEW edt_cahier_pointages AS
SELECT point_id, point_visible, point_date_crea, point_date_mod, point_user_crea, point_user_mod,
point_edt_id, point_type_id, point_com_prof, point_etu_id, etu_photo
FROM pointages
LEFT JOIN etudiants ON point_etu_id=etu_id
WHERE point_visible=1
;

Si j'enlève cette partie JOIN (qui me servait à faire remonter un champs fils de photo), alors la VIEW redevient updatable et la requpete fonctionne !

Code :

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

1
2
3
4
5
6
7
 CREATE OR REPLACE VIEW edt_cahier_pointages AS 
	SELECT point_id, point_visible, point_date_crea, point_date_mod, point_user_crea, point_user_mod, 
		point_edt_id, point_type_id, point_com_prof, point_etu_id, 'rien' AS etu_photo
	FROM pointages
 
	WHERE point_visible=1
	;

Là je ne suis pas au bureau, mais demain j'essaieré de remplacé le LEFT JOIN par un WHERE (produit cartesien).

CREATE OR REPLACE VIEW edt_cahier_pointages AS
SELECT point_id, point_visible, point_date_crea, point_date_mod, point_user_crea, point_user_mod,
point_edt_id, point_type_id, point_com_prof, point_etu_id, 'rien' AS etu_photo
FROM pointages , etudiants

WHERE point_visible=1 AND point_etu_id=etu_id

Le résultat sera le même mais pas les performances, peut-être que ça fonctionnera...

[escartefigue]

Bonjour,

à chaque fois qu'une requête comporte plusieurs tables, il est recommandé d'utiliser des alias pour préfixer chaque table et chaque colonne pour lever toute ambiguïté sur l'origine des données.

Je pense que votre problème vient de là, mais même si ce n'était pas le cas, c'est une habitude à prendre.

Toujours pour des raisons de clarté, une requête bien présentée est plus facile à lire et donc à maintenir

Exemple :

Code SQL :

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

1
2
3
4
5
6
7
8
9
create VIEW V1 as
       select T1.Col1
            , T1.Col2
            , T2.ColA
            , T2.ColB
       from ma_table1 as T1
       left join ma_table2 as T2
         on T2.ColY=T1.Col1
       where ...

[clavier12AZQSWX]

merci pour le conseil.
étant très âgé, on m'avait appris à l'époque à utiliser les alias uniquement quand 2tables avaient des noms de champs identiques et donc depuis on m'avait inculqué à ne jamais nommer pareil les champs.
Je vais tenter avec les alias, peut-être que ça peut marcher....

[clavier12AZQSWX]

bonjour,

j'ai donc testé avec la solution des ALIAS, ça n'a pas marché, toujours erreur 1288.
Par contre, avec la solition de produit cartesien + condition, ça marche.

donc j'ai changé cette creation de VIEW :

Code :

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

1
2
3
4
5
6
7
CREATE OR REPLACE VIEW edt_cahier_pointages AS 
	SELECT point_id, point_visible, point_date_crea, point_date_mod, point_user_crea, point_user_mod, 
		point_edt_id, point_type_id, point_com_prof, point_etu_id, etu_photo
	FROM pointages
	LEFT JOIN etudiants ON point_etu_id=etu_id
	WHERE point_visible=1
	;

par :

Code :

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

1
2
3
4
5
6
7
CREATE OR REPLACE VIEW edt_cahier_pointages AS 
	SELECT point_id, point_visible, point_date_crea, point_date_mod, point_user_crea, point_user_mod, 
		point_edt_id, point_type_id, point_com_prof, point_etu_id, etu_photo
	FROM pointages,etudiants
 
	WHERE point_visible=1 AND point_etu_id=etu_id
	;

merci pour l'aide suggérée.

ps : au passage, êtes-vous sur que l'alias AS se met aussi dans la déclaration de table ? je pensais que c'était réservé à la zone SELECT et que pour la table, un espace suffit à préciser l'alias

[escartefigue]

AS est facultatif que ce soit pour les alias de table ou de colonne.
Et même, dans certains cas avec d'autres SGBD, j'ai constaté que AS ne fonctionnait pas (auquel cas il suffit de ne pas le coder)


Concernant l'erreur 1288, elle n'est pas véritablement due à la syntaxe utilisant LEFT JOIN, mais au fait que plus d'une ligne est retournée par la requête.

[Artemus24]

Salut à tous.

Pourquoi tester une requête dans un SGBDR (version mariadb 10.4.8) et l'installer dans un autre SGBDR (version MySql 5.7.32) ?
Ce n'est pas très logique et cela peut provoquer des comportements différents.

On ne peux pas mettre à jour une table à partir d'une vue dont celle-ci est construite à partir de plusieurs tables.
MySql, au travers des view, ne sait mettre à jour qu'une et une seule table à la fois.
Vous devez utilisez une vue qui est extraite, même partiellement en ligne et en colonne, d'une et une seule table.
C'est pourquoi votre problème est résolue quand vous supprimez le "left outer join".

Comme résoudre votre problème ?

D'une part, n'introduisez pas la colonne "etu_photo" dans votre vue, c'est ce qui provoque votre erreur.
D'autre part, pour éviter les duplications de lignes, utilisez la clause "exists" au lieu de "left outer join".
La clause "where" peut rester en l'état.
Pour la clause "exists", il suffit de créer une sous-requête pour vérifier l'existence ou l'absence de la correspondance dans "étudiants".

@+

[clavier12AZQSWX]

Pourquoi tester une requête dans un SGBDR (version mariadb 10.4.8) et l'installer dans un autre SGBDR (version MySql 5.7.32) ?
Ce n'est pas très logique et cela peut provoquer des comportements différents.

réponse simple (même si je me sens stupide).
Nous avons pris un hébergeur récent (1&1), sans vérifier, je me suis dit (c'est forcément une version presque récente de mysql) surtout que php est 7+.
En dev, j'ai un installé un xamp avec par défaut une version très récente de mysql.

En plus avec ce changement de nom, il me semble que X sur mariaDB ne correspond pas au même X sur mysql Community.

Hier soir j'étais tombé sur une message d'une personne révellant ce problème dans le bugtracker du vieux mysql et c'était écrit "fixed" dans les versions d'après....

Quand je dis "serveur de prod", il y a aussi une version de prod avant la mise à dispo des utilisateurs; c'est là que j'ai constaté pour la 1ere fois en 2ans, ce 1er problème de version.

[tatayo]

Bonjour,

On ne peux pas mettre à jour une table à partir d'une vue dont celle-ci est construite à partir de plusieurs tables.
MySql, au travers des view, ne sait mettre à jour qu'une et une seule table à la fois.

Et pourtant, dixit la documentation c'est possible (il est vrai dans certaines conditions, qui semble pourtant réunies ici, et avec MySQL 8.0).

Mais visiblement toutes les versions ne sont pas capables de le faire...

Tatayo.

[Artemus24]

Salut Tatayo.

Tu as entièrement raison. En principe, cela devrait normalement fonctionner.

Mettre à jour une view devrait se faire de la même façon que pour une table.
Pour ma part, je fais la distinction dans l'usage que je fais des view.

J'utilise une view pour définir les restrictions d'accès des utilisateurs, à la table.
Un utilisateur aura une vue partielle soit des lignes et/ou soit des colonnes de la table.
Mais la view concernera une et une seule table.

Si j'utilise des view avec jointures, ou avec des calculs, c'est juste pour la lecture.
De ce fait, et en ce qui concerne l'exemple de clavier12AZQSWX, je ne ferai pas de mise-à-jour sur cette vue car elle accède à deux tables à la fois.

Il existe un paramétrage pouvant restreindre les accès si la clef primaire n'est pas correctement renseignée :
--> https://dev.mysql.com/doc/refman/8.0...ews_with_limit

@+