mod_roster_odbc.erl に新しい属性を追加した後、サブスクリプション プロセスで問題が発生しました。
これには明らかに、テーブル rosterusers を変更してレコードの新しい列を追加する必要があり、このモジュールの odbc_queries でクエリ get_roster (s) を追加する必要がありました。次に、モジュール mod_roster_odbc で、process_iq (get および set(s)) メソッドなどのメソッドや、record_to_string、raw_to_record、process_item_attrs、get_subscription_lists などのメソッドを拡張し、それぞれを設定するときに新しい属性を初期化する保留中のクエリを拡張する必要がありました。名簿の要素
名簿の各要素を設定するポイントまで変更をテストし、DB に正しく保存しました。名簿を取得する場合も同様で、新しい属性/レコードが期待どおりに追加されます。
さて、私の問題は、クライアント側でサブスクリプション部分を壊したことです。クライアント ロジックは名簿の各要素をサブスクライブします。これが変更される前は、オンラインの 2 つの連絡先の間で自動的にサブスクライブできました。私が理解している限り、ユーザー A はその名簿にユーザー B を設定してサブスクライブし、サーバーはこの要求でユーザー B にプレゼンスを送信して、ユーザー B がユーザー A にサブスクライブし、ユーザーが最終的に "Both" としてサブスクライブするようにします。これは、サーバーを変更した後は発生しません。
現在、ユーザー A はユーザー B をその名簿に設定できますが、オフラインで表示され、名簿ユーザーからサブスクリプションが「なし」であることがわかります。その他オンライン。ユーザー A がユーザー B サブスクリプションにメッセージを送信するまで、サブスクリプションが処理され、両方が相互にサブスクライブされます。
ここで、サーバー側でこのロジックを壊した可能性がある場所を知るためのヒントを求めているため、コードの変更を提供することは避けたいと思います。わずかな変化で壊れてしまった存在感の部分とは……。