2017-03-29 8 views
9

私は、prestashop 1.6サイトで実行するために大幅な変更を行いました。devとlive prestashopデータベースをマージする

私はローカルコピーを作成し、gitでファイルシステムの変更を追跡しています。

しかしPrestaShopの中に多くの変更は、特に私の場合には、データベースに格納されています。

  • 新しいモジュール
  • のインストールと設定ショップのカテゴリを追加し、階層を変更するモジュール
  • のアンインストール
  • モジュール位置の変更
  • 通常、どのモジュールがどのフックに表示されるかを変更します。

ライブプロセス中に、ライブサイトに多数の新しい注文、顧客、購読者などが届いているため、データベースの同期がとれていません。

DB内の特定のテーブルをダンプしてインポートするか、移行機能に組み込まれたフレームワークを使用して、他のフレームワークで同様の問題を解決しましたが、特にプレstashのアドバイスは見つかりません。

これはどのように処理されますか?

devサイトが実際よりも多様な変更を受けた可能性があることを考えれば、新しい注文などをdevサイトにコピーしてからすべてを上書きする方が簡単だろうか?

答えて

3

私はPrestaShopでこれを達成することはできないと思います。データベースをマージするには、PrestaShop DBに関する膨大な知識が必要です(つまり、データベース内のすべてのテーブルとカラムについての知識が必要です)。

これは絶対に行わないことです。

これは非常に危険な作業であり、ライブストア内のすべてのデータが失われる可能性があるため、手動で同期することをお勧めします。これはさらに苦労します。

+0

私は聞きたいものではなく、とにかく感謝します。とにかくマージを試みる前にストアをメンテナンスモードにしてバックアップしていたのですが、バックオフィスを使ってこれを手動で行うということは、店舗を数時間オフラインにすることを意味します。販売 – Steve

2

モジュールの場合、情報はすべてmodulesで始まるすべてのテーブルに格納されます。 モジュールの設定値は、configurationconfiguration_langに格納されます。もちろんカスタムモジュールテーブルもコピーしてください。

ショップカテゴリの情報は、すべての表にcategoryで始まります。

モジュールのフック情報は、すべての表にhookで始まります。

しかし、Raghubendra Singh氏の回答によると、これは非常に危険な作業です。本当にやりたければ、現在ライブサイトのローカルコピーを作成し、まず2つのローカルコピーの間でプロセスを試してみてくださいすべて正常に動作します。

+0

それは有望だ、私はいくつか注意深いローカルテストでbashスクリプトを書くことができるかもしれません。バックオフィスでの変更よりも開発者の時間がかかることはおそらくありますが、停止時間の短縮はそれをカバーする可能性があります。たとえ1番目のインスタンスではなくても、最終的には自己を支払うべきです。午前3時に仕事をしなくてもいいですよ! – Steve

0

Prestashopを更新して毎日使用していることが分かります。

毎日の作業(バグ修正や機能追加)のために、私はphpmyadminでDBの変更を直接行います。私はミラーのisntallationですべてをテストし、変更されたサイトに変更をコピーし、mysqlの変更を適用します。

私たちはサイトの2つの新しいメジャーバージョン(2年に1回程度)を取得してPrestashopの安定版を待っていましたが、今でも1.7にはいくつかの大きなバグがあります(翻訳は、それが1.7.1で100%修正されているかどうかはわかりません)。 最後の1つは、かなりうまくいって、私たちのニーズにテーマを変え、顧客のために新しい機能を適用しました...私はちょうど関連テーブルの違いを分析し、古いデータベースから新しいデータベースへのデータ、追加されたフィールドと変更されたデフォルトなど、sshアクセスは同じサーバー上に存在していました。

Btwは、アドレス、キャリア、カート、カテゴリ、顧客、配送、機能、グループ、イメージ(ただしimage_typeではなく)、製造元、受注、製品、範囲、特定価格、在庫利用可能、税金、tax_rule、wishlist、ゾーン、国、州、従業員、プロフィールなど、私たちのモジュールで使用されています。完全に新しいテーマだったので、モジュール、設定、フックなどのようなものは問題ではありませんでした。

私はいつも開発版のdbと同期して生きることができると思っていました。しかし、私たちが多くの大きな変更をしていないという事実と、それを適用するまで変更をファイルに保存しようとしているマイナーな事柄(まだ私が知っている最も専門家ではない)のせいでまだやっていません。そして時には、これらの主要なバージョンの変更によって、Prestashopが新しいやり方をすることもあります。私が最後に覚えていたのは1.6のものでアクセススラッグだった。それは1.5ではなかったし、すべてが終わった後、私はバックオフィスにログインできるが、他のワーカーはアクセスの制御方法が変わったためできなかった。私はsuperadminだったので、私はそれによって影響を受けなかった。 PrestashopはSymfonyを使い始めています。私はこれを将来もっと使いこなし、今後どのようなことが起こるかに影響を与えると考えています。だから、今のところ解決策ができないだろう。

アップグレード機能をモジュールで使用することもできます。試したことはありませんが、データベースやその他のアップグレードを自動的に適用するために使用できます。有望に見えますが、プッシュで動作するのか、モジュールのアップグレードのみで動作するのかはわかりません。最近、私はこれをテストしようとしています。

これは解決策の回答ではありませんが、私は興味があり、問題がなければ問題に取り組んでいます。プッシュを行い、dbで "手作業で"変更する必要はありません。

+0

モジュールがPrestashop Addonsにないかぎり、モジュールリストページをロードするとすぐにアップグレードが実行されます。また、アップグレードスクリプトが一度だけ実行されるため、変更を反映するために元のインストールSQLコード/ファイルをすべて変更する必要があります。モジュールを再インストールすると、アップグレードスクリプトは実行されません。 – TheDrot

+0

これは知っておきたいことです。プッシュ/プルが各モジュールのアップグレードチェックを引き起こす可能性があります。再インストールすると、アップグレードが行われたでしょう。インストール時に、最新の構造を反映するようにテーブルを作成するコードを変更する必要がありました。 – sadlyblue

+0

それはちょうど理論です – Wolfack

関連する問題