Discussion :

[coupolites]

Bonjour à tous,

A chaque fois que génère mon schema.yml en fonction de ma bdd je perd le "actAs : Timestampable". (normal ?)

Je suis moyennement à l'aise avec le schema.yml j'utilise donc l'interface de phpMyAdmin pour la création de mes tables...

Y a t il un autre moyen pour gérer le "timestample" ?

Merci d'avance

[Michel Rotta]

??

A mon avis tu utilises tout a l'envers...

Tu as deux possibilités :

• Récupération d'une structure déjà définie (par phpMyAdmin ou autre), qui va te récupérer un schema et te créer les modules, form, et filter qui vont avec
• Création d'un shema.yml et génération de la base avec le build de doctrine.

Si tu mélanges les deux il n'y a aucune chance que cela marche.

[coupolites]

??

A mon avis tu utilises tout a l'envers...

Tu as deux possibilités :

• Récupération d'une structure déjà définie (par phpMyAdmin ou autre), qui va te récupérer un schema et te créer les modules, form, et filter qui vont avec
• Création d'un shema.yml et génération de la base avec le build de doctrine.

Si tu mélanges les deux il n'y a aucune chance que cela marche.

merci pour ta réponse,

Mais comment faire si je veux créer ma structure via phpMyAdmin mais avec des champs "timestample" ?

Merci

[sacricri]

merci pour ta réponse,

Mais comment faire si je veux créer ma structure via phpMyAdmin mais avec des champs "timestample" ?

Merci

Bonjour,

Tu peux toujours générer ton schema.yml une fois ta base de données créée via PHPMyAdmin puis modifier ce schema.yml en ajoutant le actAs et alors générer un migration de doctrine (doctrine:generate-migrations-diff) et lancer un

Code :

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

symfony doctrine:build --all-classes --and-migrate

[coupolites]

Bonjour,

Tu peux toujours générer ton schema.yml une fois ta base de données créée via PHPMyAdmin puis modifier ce schema.yml en ajoutant le actAs et alors générer un migration de doctrine (doctrine:generate-migrations-diff) et lancer un

Code :

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

symfony doctrine:build --all-classes --and-migrate

C'est ce que je fais actuellement (sauf que je fais un build --and load -all) mais le problème c'est que je suis au début du projet donc la base "change régulièrement" et lorsque que je régénère" mon schema.yml je perd mon timestample.

Sinon que fais exactement le -migrate ?

Merci de ton aide

[sacricri]

Sinon que fais exactement le -migrate ?

Le migrate lance la migration. En gros, il vérifie qu'il existe des fichiers de migrations et la lance. Donc vérification de la version actuelle, mise à jour si nécessaire, etc.

[jeronimo83]

C'est ce que je fais actuellement (sauf que je fais un build --and load -all) mais le problème c'est que je suis au début du projet donc la base "change régulièrement" et lorsque que je régénère" mon schema.yml je perd mon timestample.

Sinon que fais exactement le -migrate ?

Merci de ton aide

Je veux bien comprendre que ta base puisse changer, mais je ne comprends pas que tu perdes le timestampable.

Quand tu fais ton doctrine:build-all il devrait te dire que ca va écraser ta bdd et ca devrait te la regénérer avec ton timestampable si il est bien précisé dans ton shema.yml.

Peux être a t'il une erreur mais si c'était le cas ta base ne serait pas regénéré, étrange que tu perdes tes champs relatifs au timestampable.

Code :

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

1
2
3
4
5
6
7
8
9
10
 
---
# schema.yml
 
# ...
BlogPost:
  actAs:
# ...
    Timestampable:
# ...

[coupolites]

Je veux bien comprendre que ta base puisse changer, mais je ne comprends pas que tu perdes le timestampable.

Quand tu fais ton doctrine:build-all il devrait te dire que ca va écraser ta bdd et ca devrait te la regénérer avec ton timestampable si il est bien précisé dans ton shema.yml.

Peux être a t'il une erreur mais si c'était le cas ta base ne serait pas regénéré, étrange que tu perdes tes champs relatifs au timestampable.

Code :

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

1
2
3
4
5
6
7
8
9
10
 
---
# schema.yml
 
# ...
BlogPost:
  actAs:
# ...
    Timestampable:
# ...

Oui j'ai bien le message indiquant que toute ma base sera écrasée....
Après la question est : est ce que la propriété timestampable existe dans phpmyadmin ?

En plus je viens de remarquer que je perd également l'encodage de base il est en utf8 et quand je génère la base via "symfony doctrine:build-all ..." toute ma base passe en latin1_swedish_ci. pourtant dans mon database.yml j'ai bien encoding: utf8 !

Merci

[Invité]

Si je comprend bien tu procède comme ceci :

1/ Tu modélise manuellement ta base via Phpmyadmin
2/ Tu génère ton schema.yml à partir de la base de donnée
3/ Tu ajoutes tes actAs: Timestampable
4/ Tu build tes classes PHP

Et ensuite, quand tu refais des modifs :

5/ Tu fais tes modifs via PhpMyAdmin
6/ Tu repars au 2/

A mon avis, si tu fais ça, c'est normal que tu perdes tes actAs. Je pense pas que Doctrine soit capable de replacer des Behaviors dans le schema.yml en partant d'une base de données.

Je te suggère de te familiariser avec le schema.yml plutôt

[coupolites]

Si je comprend bien tu procède comme ceci :

1/ Tu modélise manuellement ta base via Phpmyadmin
2/ Tu génère ton schema.yml à partir de la base de donnée
3/ Tu ajoutes tes actAs: Timestampable
4/ Tu build tes classes PHP

Et ensuite, quand tu refais des modifs :

5/ Tu fais tes modifs via PhpMyAdmin
6/ Tu repars au 2/

A mon avis, si tu fais ça, c'est normal que tu perdes tes actAs. Je pense pas que Doctrine soit capable de replacer des Behaviors dans le schema.yml en partant d'une base de données.

Je te suggère de te familiariser avec le schema.yml plutôt

Merci pour ta réponse.

Et pour l'interclassement qui est en latin1_swedish_ci par défaut dans la base comment puis je le changer via le schema.yml (ou un autre fichier)

[Invité]

Il me semble que tu peux mettre tout en haut de ton schema.yml :

Code :

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

1
2
3
4
 
options:
  collate: utf8_unicode_ci
  charset: utf8

Sinon tu peux aussi aller changer la conf de mysql, dans le fichier my.cnf, ajouter dans la section [mysqld] (J'ai trouvé ça sur le net, je sais pas si ça fonctionne )

Code :

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

1
2
3
4
5
6
 
default-character-set=utf8
default-collation=utf8_unicode_ci
character_set_server=utf8
collation_server=utf8_unicode_ci
default-storage-engine=INNODB

[coupolites]

Il me semble que tu peux mettre tout en haut de ton schema.yml :

Code :

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

1
2
3
4
 
options:
  collate: utf8_unicode_ci
  charset: utf8

Sinon tu peux aussi aller changer la conf de mysql, dans le fichier my.cnf, ajouter dans la section [mysqld]

Code :

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

1
2
3
4
5
6
 
default-character-set=utf8
default-collation=utf8_unicode_ci
character_set_server=utf8
collation_server=utf8_unicode_ci
default-storage-engine=INNODB

On avance !
Le utf8_unicode_ci dans le schema.yml marche mais pas pour les tables sfGuard ! Est ce normal ? Il me change bien l'interclassment pour toutes les autres tables.

De plus l'encodage de ma base elle aussi reste en latin....

encore merci pour ton aide

[Invité]

La base c'est normal oui et je pense pas que ce soit dérangeant si tes tables ont bien le bon truc, et que les champs textes dans tes tables aussi.
Pour la base le seul choix va être la modification des paramètres de MySQL pour lui dire que le jeu de caractère par défaut c'est l'utf8. Mais comme je le dis, je pense pas que ça soit grave si tu ne le fais pas.

Bon sinon, je crois que je viens de trouver encore un nouveau truc. Tu devrais pouvoir enlever les lignes de ton schema.yml, et à la place, tu mets dans ta classe ProjectConfiguration :

Code :

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

1
2
3
4
5
6
 
public function configureDoctrine(Doctrine_Manager $manager)
{
  $manager->setCollate('utf8_unicode_ci');
  $manager->setCharset('utf8');
}

Et là même les tables de tes plugins devraient être en utf8

[coupolites]

La base c'est normal oui et je pense pas que ce soit dérangeant si tes tables ont bien le bon truc, et que les champs textes dans tes tables aussi.
Pour la base le seul choix va être la modification des paramètres de MySQL pour lui dire que le jeu de caractère par défaut c'est l'utf8. Mais comme je le dis, je pense pas que ça soit grave si tu ne le fais pas.

Bon sinon, je crois que je viens de trouver encore un nouveau truc. Tu devrais pouvoir enlever les lignes de ton schema.yml, et à la place, tu mets dans ta classe ProjectConfiguration :

Code :

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

1
2
3
4
5
6
 
public function configureDoctrine(Doctrine_Manager $manager)
{
  $manager->setCollate('utf8_unicode_ci');
  $manager->setCharset('utf8');
}

Et là même les tables de tes plugins devraient être en utf8

malheureusement la il n'y a plus rien en utf8

[Invité]

Ca marche bien chez moi sur une 1.4.4 pourtant. Sur un projet vierge avec sfDoctrineGuardPlugin.

[Invité]

Aller je suis joueur. Encore un essai :

- Rien dans ton schema.yml
- Tu enlèves la méthode configureDoctrine de ton ProjectConfiguration
- Tu ajoutes ceci (que je met en rouge) dans ton database.yml :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
all:
  doctrine:
    class: sfDoctrineDatabase
    param:
      dsn:      mysql:host=localhost;dbname=fake_project
      username: root
      password:
      attributes:
        default_table_collate: utf8_unicode_ci
        default_table_charset: utf8

[coupolites]

Aller je suis joueur. Encore un essai :

- Rien dans ton schema.yml
- Tu enlèves la méthode configureDoctrine de ton ProjectConfiguration
- Tu ajoutes ceci (que je met en rouge) dans ton database.yml :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
all:
  doctrine:
    class: sfDoctrineDatabase
    param:
      dsn:      mysql:host=localhost;dbname=fake_project
      username: root
      password:
      attributes:
        default_table_collate: utf8_unicode_ci
        default_table_charset: utf8

Toutes la tables sont ok ! Il manque juste la base en elle même

Est ce que j'utilise la bonne commande : "symfony doctrine:build --and -load -all"

Merci

[Invité]

Oui. La base tu ne pourras rien y faire je pense. C'est pareil chez moi.

Le seul moyen c'est de changer la configuration de mysql de façon à définir le jeu de caractère par défaut comme étant utf8

[coupolites]

Oui. La base tu ne pourras rien y faire je pense. C'est pareil chez moi.

Le seul moyen c'est de changer la configuration de mysql de façon à définir le jeu de caractère par défaut comme étant utf8

Malheureusement je peux pas touché la config de mysql.

Donc un grand merci pour ton aide.

Sinon pour l'histoire du timestample c'est normal ?
Dernière question y a t il une commande pour tout générer à partir du schema.yml genre "doctrine:build --all" mais pour garder les données en base. Car j'utilise la commande symfony doctrine:build --and -load -all mais je ne comprend pas ce qu'il load car il m'écrase tout !