Quelles sont les tables potentiellement modifiées via le Front Office ?

[msevestre]

Bonjour

 

j'explique mon besoin: j'ai deux sites : un de production et un de pré-production.

 

Mon idée est de gérer via le back office sur le site de pré-production puis ensuite balancer les tables impactées sur le site de production via mysqldump au travers d'un scripts exécuté la nuit, le tout sans interruption du site de production (je ne souhaite pas mettre en maintenance le site de vente, le temps de mettre à jour tous mes produits en parallèle par exemple (ce que je ferais plus volontiers la journée que la nuit par ailleurs)).

 

Pour cela, j'ai besoin de savoir les tables qui sont potentiellement impactées par les actions du front office : celles du site de production resteront alors inchangées par une exclusion de ces tables lors du mysqldump de pre-prod.

 

Par exemple les tables client sont altérées par des actions font office : je ne réinjecterais pas celles de mon site de pre-prod.

 

D'une manière plus pernicieuse, la table des adresses est partagée entre le front office et le back office (adresses des clients et des fournisseurs par ex sont contenues dedans) => celle du site de production restera prioritaire donc inchangée et sera gérée par des actions spécifiques

 

Quelqu'un s'est-il déjà attelé à cette liste des tables uniquement modifiables via le back office (les tables ps_products* par exemple sont de cette catégorie pour moi) ?

 

J'ai déjà commencé ce travail de tri, mais je redoute que ma jeunesse avec PS me joue des tours.

 

PS: à noter que je suis en drop shipping, donc les stocks issus du site de production ne sont pas une donnée à ne pas perdre.

 

Merci

Matt

 

Je tourne sous PS 1.4.5.1.

[vins]

Je serais aussi grandement intéressé par la réponse !

[jeckyl]

Bonjour,

 

je ne comprends pas du tout l'intérêt de multiplier les sites pour n'en gérer qu'un seul.

 

Quel peut être le problème de gérer votre boutique sur celle de production ?

 

Vous pouvez très bien faire des fiches produits et ne les activer que lorsqu'elles sont prêtes, comme pour tout le reste.

 

Que vous ayez un site de test pour tester les modules avant de les mettre sur le site de prod, ou encore tester des modifications du design, je comprends et jke le conseil mais que je sache, dans une boutique physique vous n'avez pas une seconde boutique cachée dans un coin pour faire comme si.

 

Donc merci de bien vouloir m'expliquer le concept qui peut amener à faire cette demande.

[msevestre]

Bonjour

 

j'ai mené à bien mes recherches pour information.

 

Alors quel intérêt... Nous avons trois sites:

- un de production, qui n'a de spécifique que le thème et qui ne servira qu'à gérer les aspects fonctionnels (commandes)

- une version pre-production sur laquelle nous gérons les CMS, les fiches produit, documents liés, etc.

- une version test

 

Ceci nous permet:

- de dumper prod-> test => pour réaliser en situation "réelle" (site identique) des test & des modifs avant intégration dans prod

- d'envoyer le contenu modifié sur preprod vers test et prod => permet de vérifier sur le site de test, avant mise en production, que tout est OK

- de conserver le site de preprod sur le template officiel : nous avons un template "maison" et certains comportement peuvent différer dans ce cas, ca nous permet de voir si le bug vient de mon template ou d'ailleurs.

 

Le réel intérêt : je peux mettre le site de preproduction dans les mains de quelqu'un pour faire de la saisie produit pure: aucun accès ne sera possible aux données clients, factures, etc. puisque preproduction ne contient aucune de ces données.

 

bref là maintenant j'ai trois scripts que je peux lancer:

- dump prod->test

- copie des données preprod -> test

- copie des données preprod -> prod

 

 

Il est est vrai qu'avoir un site de "preproduction" est peu utile à priori, mais mon passé m'a prouvé que cela pouvait servir (comportement inattendus, erreurs d'ecriture sur la base de donnée ... et là c'est tout le site de prod qui est HS si on bosse direct sur prod). Par ailleurs, ca permet aussi d'utiliser des outils comme QuickUpdate et Store Commander mais comme ma confiance n'est pas à 100% sur ces outils, ne pas les mettre en oeuvre sur le site de production me va bien (récemment encore, trouvé un bug sur SCFree et les produits liés à télécharger... ca m'avait endommagé ma base de preprod, mais le site de prod n'a pas eu de soucis)

 

C'est plutôt une habitude que j'ai, lié à mes origines professionnelles de l'industrie : je préfère tout vérifier offline, avant mise en production.

 

 

Matt

[jeckyl]

Ah ok, je comprends mieux, une simple sauvegarde de base de données avant d'intervenir sur le serveur de prod ne suffirait pas.

 

si votre site de prod n'est pas parfait à 100% pour la modification de vos fiches produits, vous devriez aussi faire un site de precommande pour les clients car peut être que leur commande pourrait détruire votre base de données puisque une seule commande provoquera plus de changement que l'enregistrement d'un produit.

 

Mais aussi faire 3 sites pour les statistiques afin d’être sûr que celles ci ne pourraient pas détruire votre base de données.

 

Bon j'exagère mais je ne fait que reprendre votre argumentaire.

 

Que vous ayez une version de test pour valider le fonctionnement de modules et de template c'est une obligation car il serait dommage de détruire votre site de prod pour un soucis de compatibilité de votre template avec un module ( ce qui ne devrait pas trop arriver si le template est bien fait ainsi que le module). De plus cela permet de tester les mises à jours de prestashop.

 

Je ne vais pas me pencher sur les interactions entre les tables mais en regardant les clés externes de chaque tables vous devriez pourvoir faire le rapprochement.

[msevestre]

Bonsoir

 

Chacun fonctionne comme il l'entend

 

Concernant ma demande initiale, je suis parvenu à mes fins 8 jours après ma demande, en analysant les tables. Et toutes mes bascules se font au travers de 3 scripts comme indiqué dans ma précédente réponse

 

Matt

[jeckyl]

Pourriez vous transmettre à la communauté l'ensemble de votre analyse afin de satisfaire des besoins comme le votre par la suite ?

[msevestre]

Oui je le ferais demain

 

Matt

[jeckyl]

ok, merci d'avance.

[doekia]

Salut,

 

Pourquoi ne pas avoir utilisé les webservices?

Certaines informations du pré-prod ne me semblent pas pertinente pour le transfert.

- adresse, client, ...

 

J'avais avant la 1.4 une gestion de replicat en utilisant des trigger SQL, et des vues pour certaines données totalement partagées (devise, taxes, pays, ...)

J'ai arrêté de réfléchir à ce problème car la 1.5 permettra très justement de répondre à cette attente (une zone où l(on prépare les fiches produits (traduction, argumentaire commercial, et une zone propre et nette pour la vente ).

Mais je devait m'y ré-atteler je ciblerais les webservices comme piler de communication

 

Cordialement,

(d)oekia

[msevestre]

Hello

 

la 1.5 elle n'est pas encore là et nous avons démarré avec la 1.4.4.1 avec un swicth rapide vers 1.4.5.1 qui est arrivée peu de temps après.

 

Pourquoi ne pas avoir utilisé les webservices : tout simplement car mes compétences techniques en technos web ne sont à ce jour pas exhaustives, loin de là. Je découvrais en même temps CSS, prestashop et je devais me rappeler de mes bases de SQL... donc assez de choses à voir à ce moment... sans parler de la remontée de la base de produits.

 

Par ailleurs, ne pas tout exporter de preprod vers prod était justement l'objectif et j'y suis parvenu.

 

Voici donc les tables que j'exporte :

 

ps_accessory \
ps_alias \
ps_attachment \
ps_attachment_lang \
ps_attribute \
ps_attribute_group \
ps_attribute_group_lang \
ps_attribute_impact \
ps_attribute_lang \
ps_carrier \
ps_carrier_group \
ps_carrier_lang \
ps_carrier_zone \
ps_category \
ps_category_group \
ps_category_lang \
ps_category_product \
ps_cms \
ps_cms_block \
ps_cms_block_lang \
ps_cms_block_page \
ps_cms_category \
ps_cms_category_lang \
ps_cms_lang \
ps_compare_product \
ps_contact \
ps_contact_lang \
ps_country \
ps_country_lang \
ps_county \
ps_county_zip_code \
ps_currency \
ps_delivery \
ps_feature \
ps_feature_lang \
ps_feature_product \
ps_feature_value \
ps_feature_value_lang \
ps_image \
ps_image_lang \
ps_image_type \
ps_importfast \
ps_import_match \
ps_lang \
ps_log \
ps_manufacturer \
ps_manufacturer_lang \
ps_meta \
ps_meta_lang \
ps_operating_system \
ps_order_message \
ps_order_message_lang \
ps_pack \
ps_product \
ps_product_attachment \
ps_product_attribute \
ps_product_attribute_combination \
ps_product_attribute_image \
ps_product_country_tax \
ps_product_download \
ps_product_group_reduction_cache \
ps_product_lang \
ps_product_sale \
ps_product_tag \
ps_quick_access \
ps_quick_access_lang \
ps_range_price \
ps_range_weight \
ps_referrer \
ps_referrer_cache \
ps_required_field \
ps_scene \
ps_scene_category \
ps_scene_lang \
ps_scene_products \
ps_search_engine \
ps_search_index \
ps_search_word \
ps_sekeyword \
ps_specific_price \
ps_specific_price_priority \
ps_state \
ps_store \
ps_subdomain \
ps_supplier \
ps_supplier_lang \
ps_tab \
ps_tab_lang \
ps_tag \
ps_tax \
ps_tax_lang \
ps_tax_rule \
ps_tax_rules_group \
ps_timezone \
ps_webservice_account \
ps_webservice_permission \
ps_web_browser \
ps_zone \

 

En plus de cela, sont recopiés les répertoires download et img.

 

Matt

[doekia]

web_broowser, referer, referer_cache, operating_system, search_engine sont des tables statistiques

log les logs d'erreurs

quick_access, quick_access_lang sont les acces rapides du BO

tab, tab_lang la liste des onglets

search_index et search_word sont lié au moteur de recherche et dépendent de la configuration donc il vaut mieux régénérer l'index de recherche après transfert

 

Voilà un commentaire en 2 minutes, si ça peut aider

 

Cdlt,

(d)oekia

[msevestre]

Merci, je vais regarder cela.

[msevestre]

Hello

 

j'ai supprimé de min transfert les tables citées par doekia

 

Matt