J'ai modifier la table jacluser en ajoutant notemment une clé primaire numérique auto incrémenté et en mettant le champs login à unique et non clé primaire.

Je me demandais si cette modification peut poser des problèmes dans les modules préfaient de jelix?

A priori non car je n'ai pas de bug, mais je préfère avoir une réponse des pros. :-) isdream.

J'ai modifier la table jacluser en ajoutant notemment une clé primaire numérique auto incrémenté et en mettant le champs login à unique et non clé primaire.

Je ne suis pas sûr que jAcl risque de bien fonctionner après ça, et je pense que c'est une mauvaise idée. Si en plus le login est unique, pourquoi ne pas s'en servir comme clé primaire ? Pourquoi avoir ce besoin précisément ?

J'ai toujours appris à faire des liens avec les numéros de tables. Donc par exemple dans une table article écrit par un "login" j'aurai une clé étrangère de type numéro et non de type chaine dans ma table article. Il me semble que c'est plus rapide pour le traitement même si le temps gagné est marginal.

Peut être que je me trompe.

Pour l'utilisation du module jacl j'applique l'utilisation du login tel quel, mais j'applique un numéro pour les autres tables (table article par exemple).

Pour l'instant cela à l'air de marcher, si il y a des erreurs je reviendrai sur l'utilisation du login en clé. :-)

isdream. Note : Pour etre clair j'ai fais ma base de données avec une table PERSONNE(PER_ID,PER_NOM,PER_TEL...etc), dont l'identifiant est PER_ID. Et PER_ID est dans pas mal de mes tables liés à PERSONNE. Et finalement j'ai unis la table PERSONNE à jacluser.

Au lieu de changer toutes mes tables "lié" à PERSONNE j'ai choisi de mettre PER_ID en identifiant de ma nouvelle table jacluser. :-)

dans ce cas, je ne comprends pas pourquoi per_id est en autoincrement de la table jacluser, puisque si j'ai bien compris, per_id est la clé primaire de PERSONNE. Aussi le per_id dans jacluser ne devrait être qu'une clé étrangère, non pas une clé primaire en autoincrement.

Oups, j'ai pensé plus vite que j'ai écrit. J'ai oublié de dire que l'idée principal que j'ai appliquée est la fusion des deux tables en une seule. Les données de PERSONNE sont donc maintenant dans la table jacluser.

1. Donc soit je revient sur deux tables séparées. Pour rendre les choses très propre je devrais peut être laisser les deux tables séparer. Mais je pense que c'est une sorte d'optimisation (voir mon explication ci dessus).

2. Soit une table fusionnée avec "login" clé primaire.

3. soit une table fusionné avec "login" non clé primaire.

Sans contrefaire ou altéré le framework j'aimerai utiliser la 3eme solution. ( Je m'excuse car ce sujet pourrait s'apparenter à du "trolling" jusque là :-(, enfin j'espère pas car le choix n'est pas la question en fait.)

Donc voila le bilan : Login n'est plus clé primaire. Mes 2 questions sont :

Est ce que cela risque de poser des problème maintenant? (a priori non, car je n'ai pas de problème avec jacl).

Et pour plus tard? (surement mais peut etre pas)

isdream.

Les données de PERSONNE sont donc maintenant dans la table jacluser.

Ok, dans ce cas il est logique que ton champs soit en autoincrement.

Est ce que cela risque de poser des problème maintenant?

Disons que jAcl n'a pas été conçu pour ce fonctionnement.

Et pour plus tard?

Je ne peux le garantir. Par exemple, le module jxacl, l'interface pour gérer les droits, ne prend absolument pas en compte cet identifiant : à mon avis donc son utilisation n'est pas possible avec ta modification.

En fait, pour que ça ait des chances de fonctionner à l'avenir, il faudrait que tu gardes le champs login en temps que clé primaire, et le champs id resterait en autoincrement, mais avec un simple index dessus (ou index UNIQUE).

Merci de ton aide, ta solution résolu mon (futur) problème.

isdream.