[sf 1.4.x] Sauvegarder un formulaire embarqué de type n-n

[Herode]

Bonjour à tous,

soit le modèle suivant :

• un panier contient plusieurs lignes
• une ligne de panier déclare une ou plusieurs confections

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
Cart:
  columns:
    # forfait façonnage
    net_making_fees: { type: float, default: 12 }
  relations:
    Products:
      foreignAlias: Carts
      class: Product
      refClass: CartItem
 
CartItem:
  columns:
    quantity: { type: integer }
    width: { type: float }
    height: { type: float }
  relations:
    Cart:
      foreignAlias: Items
    Product:
      foreignAlias: CartItems
 
Confection:
  columns:
    name: { type: string(45) }
  relations:
    CartItems:
      class: CartItem
      foreignAlias: Confections
      refClass: CartItemConfection
 
CartItemConfection:
  columns:
    cart_item_id: { type: integer, notnull: true }
    confection_id: { type: integer, notnull: true }

Sur ce schéma banal, si je générère le module CartItem avec doctrine et que j'édite un CartItem, je tombe sur un formulaire classique avec les champs width, height, quantity, confections_list. Si j'ajoute ou que je supprime une confection pour ce CartItem et que j'enregistre tout ça, tout marche.

Fort de ce constat, je cherche à embarquer ce formulaire dans le formulaire de gestion du Panier. Je fais donc le embedRelation('Items') requis dans le configure() du CartForm. Je génère mon module Cart avec Doctrine, je vais en édition sur l'un des paniers enregistrés, je vois bien mes sous-formulaires CartItem. Si je modifie uniquement quantity, width ou height sur l'un des CartItems de mon panier et que j'enregistre, tout va bien. Par contre, si je modifie la liste de confections d'un CartItem, cette modification n'est pas sauvegardée (les autres le sont toujours, elles).

C'est contrariant

[Michel Rotta]

Ton shéma n'est pas viable ainsi, il manque des tables.

Il y a à priori deux relations n-n, mais les relations ne sont pas correctement déclarées CartItemConfection semble être utilisée comme table pivot, mais la clef primaire ne prends pas les clefs externes en compte, ce qui est sujet à problèmes.

De plus, il semblerait que CartItem soit vue comme une table de liaison n-n entre produc et"je ne sais pas trop quoi", mais sans aucune clefs primaires ni liaisons.

Ce qui me donne l'impression que tu chaines deux tables de liaison ensemble.

Il faudrait consolider ton shéma avant de tenter quoi que cela soit d'autre. L'actuel me semble voué à l'échec.

[Herode]

Non, les colonnes qui te manquent y sont, j'ai juste élagué (un peu brutalement, soit, et incomplètement, j'aurais pu virer aussi la relation vers Product). Le schéma complet possède en effet un enchainement de tables n-n : CartItem fait une liaison n-n entre Cart et Product, CartItemConfection fait une liaison n-n entre CartItem et Confection. Mais Product ne nous intéresse pas ici, on peut l'ignorer. Le problème se manifeste dans la chaine Cart - CartItem - CartItemConfection - Confection, les formulaires en jeu sont ceux de Cart (formulaire principal) et CartItem (enchâssé dans CartForm)

Quelques recherches sur la Toile m'ont permis de confirmer que je ne suis pas le seul à avoir eu ce problème, on devrait pouvoir le reproduire facilement avec n'importe quel groupe de 3 tables liées pareillement : table A (Cart) et table B (CartItem) en relation 1-n, table B et table C (Confection) en relation n_n.

[Michel Rotta]

Ceci n'est pas conforme à la structure d'une table de liaison n-n.

Code :

1
2
3
4
5
 
CartItemConfection:
  columns:
    cart_item_id: { type: integer, notnull: true }
    confection_id: { type: integer, notnull: true }

il devrait être comme ceci :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
CartItemConfection:
  columns:
    cart_item_id:
      type: integer
      notnull: true
      autoincremant: true
    confection_id:
      type: integer
      notnull: true
      autoincremant: true
  relations:
    CartItem:
      local: cart_item_id
      foreignAlias: CartItemConfections
    Confection:
      foreignAlias: CartItemConfections

Par rapport à ta question, tu parles d'un champ "champs classique ... confection_list". Il est classique comment ? Quel widget et quel champ du modèle sont derrière ?

[Herode]

Non non, toutes ces colonnes y sont. Je comptais simplifier la discussion et gagner du temps en élaguant le schéma pour n'y montrer que le strict minimum mais il semble que ma tentative maladroite s'achève en "epic failure"

J'ai provisoirement contourné le problème en collant des appels Ajax sur mon formulaire pour mettre à jour la table concernée. Dès que j'ai le temps, je construis un modèle et un programme de test simplifié (mais complet ) pour isoler, reproduire et discuter plus clairement du problème.

[Michel Rotta]

Ma remarque sur les tables manquantes n'était que cosmétique. Destinée à essayer de comprendre une structure complexe de pas ces besoins.

Par contre, ma remarque sur la structure de la table pivot : CartItemConfection est elle conceptuel. En effet, une table pivot (sauf rares exceptions) doit avoir ces champs, ces arguments et ces relations.

Je te laisse revoir pour la question de base, et revenir par après. Mais je reste curieux sur ce que peut bien être le champ : "confection_list" ???