Serialize the ContactManager

Review Request #2054 — Created Nov. 10, 2022 and updated

Information

pidgin/pidgin
default

Reviewers

This is saved in a SQLite database inside the user config directory named
contacts.db. It does its best to synchronize with PurpleBuddy, but not
everything emits a signal when it changes.

Also, stuff like custom avatars are ignored as those are currently store
on the Contact and we don't have a mapping to PurplePerson yet.

Ran with the demo account and verified everything about the contacts was stored via the sqlite3 command line.

Summary ID
Serialize the ContactManager
This is saved in a SQLite database inside the user config directory named contacts.db. It does it's best to synchronize with PurpleBuddy, but not everything emits a signal when it changes. Also, stuff like custom avatars are ignore as those are currently store on the Contact and we don't have a mapping to PurplePerson yet.
5ba998bd1b25c115904aab504d80b2fd6531a2a9
Description From Last Updated

Figure out how to handle unit tests. This doens't know when we're testing or not, so it always tries to …

grimgrim

Does this need a rebase for PurpleContactInfo stuff?

QuLogicQuLogic

Why is this in the account manager header?

QuLogicQuLogic

NULL works here.

QuLogicQuLogic

name and value are not freed here.

QuLogicQuLogic

name and value are not freed at the end of the loop.

QuLogicQuLogic

Not sure why this calls sync_tags but not update_contact_tags? And should everything get a transaction around it?

QuLogicQuLogic

Ditto.

QuLogicQuLogic

Don't need the semicolon, I think?

QuLogicQuLogic

Extra tab?

QuLogicQuLogic

Would contacts ever change accounts?

QuLogicQuLogic

sqlite3_prepare_v2 is preferred.

QuLogicQuLogic

stmt is not finalized in error or success.

QuLogicQuLogic

stmt is not finalized in error or success.

QuLogicQuLogic

I believe it might be better to prepare this outside the loop, and bind/step inside only. See lifecycle at https://www.sqlite.org/c3ref/stmt.html

QuLogicQuLogic

But if stmt preparation is not moved outside the loop, then this one is not finalized in the case of …

QuLogicQuLogic

But if stmt preparation is not moved outside the loop, then this one is not finalized in the case of …

QuLogicQuLogic

Same here about moving outside loop.

QuLogicQuLogic

Same here about finalizing on success.

QuLogicQuLogic

Can move into the only if that uses it.

QuLogicQuLogic

It's just gpointer.

QuLogicQuLogic

Can be combined into g_clear_list.

QuLogicQuLogic
QuLogic
grim
grim
QuLogic
  1. 
      
  2. libpurple/purpleaccountmanager.h (Diff revision 2)
     
     

    Why is this in the account manager header?

    1. I must have fixed up my open files...

  3. libpurple/purplecontactmanager.c (Diff revision 2)
     
     

    NULL works here.

  4. libpurple/purplecontactmanager.c (Diff revision 2)
     
     

    name and value are not freed here.

    1. They're free'd via the bind method.

      I used the following POC to test. Notice the typo in the statement, you can correct it and verify that we still get double free's for both success and failure.

      #include <glib.h>
      #include <sqlite3.h>
      
      int
      main(int argc, char *argv[]) {
          sqlite3 *db = NULL;
          sqlite3_stmt *stmt = NULL;
          char *bar = NULL;
      
          sqlite3_open(":memory:", &db);
      
          sqlite3_prepare(db, "select * from foo wher bar=?", -1, &stmt, NULL);
      
          bar = g_strdup("allocated string");
      
          sqlite3_bind_text(stmt, 1, bar, -1, g_free);
      
          sqlite3_step(stmt);
      
          g_free(bar);
      
          return 0;
      }
      
    2. Derp, this was supposed to be on the other comment below. This block was leaking.

  5. libpurple/purplecontactmanager.c (Diff revision 2)
     
     

    name and value are not freed at the end of the loop.

    1. They're free'd via the bind method.

    2. See the comment above for why this is already free'd.

  6. libpurple/purplecontactmanager.c (Diff revision 2)
     
     
     
     

    Not sure why this calls sync_tags but not update_contact_tags? And should everything get a transaction around it?

  7. libpurple/purplecontactmanager.c (Diff revision 2)
     
     
     
     
  8. libpurple/purplecontactmanager.c (Diff revision 2)
     
     

    Don't need the semicolon, I think?

  9. 
      
grim
  1. 
      
  2. Figure out how to handle unit tests. This doens't know when we're testing or not, so it always tries to create purple_user_config_dir() / 'contacts.db' which causes failures.

  3. 
      
grim
QuLogic
  1. 
      
  2. Does this need a rebase for PurpleContactInfo stuff?

  3. libpurple/purplecontactmanager.c (Diff revision 3)
     
     

    Extra tab?

  4. 
      
grim
Review request changed

Change Summary:

rebase, fix whitespace

Commits:

Summary ID
Serialize the ContactManager
This is saved in a SQLite database inside the user config directory named contacts.db. It does it's best to synchronize with PurpleBuddy, but not everything emits a signal when it changes. Also, stuff like custom avatars are ignore as those are currently store on the Contact and we don't have a mapping to PurplePerson yet.
d56d5b5ae5213ec31d9468012801c73c5ab1a694
Serialize the ContactManager
This is saved in a SQLite database inside the user config directory named contacts.db. It does it's best to synchronize with PurpleBuddy, but not everything emits a signal when it changes. Also, stuff like custom avatars are ignore as those are currently store on the Contact and we don't have a mapping to PurplePerson yet.
5ba998bd1b25c115904aab504d80b2fd6531a2a9

Diff:

Revision 4 (+994 -10)

Show changes

QuLogic
  1. 
      
  2. libpurple/purplecontactmanager.c (Diff revision 4)
     
     
     
     

    Would contacts ever change accounts?

    1. A contact is supposed to just tie a contact info to an account, so they shouldn't.

    2. Should there be account_id in the UPDATE then, or should it be part of the WHERE?

  3. libpurple/purplecontactmanager.c (Diff revision 4)
     
     

    sqlite3_prepare_v2 is preferred.

  4. libpurple/purplecontactmanager.c (Diff revision 4)
     
     
     
     
     
     
     
     
     

    stmt is not finalized in error or success.

  5. libpurple/purplecontactmanager.c (Diff revision 4)
     
     
     
     
     
     
     
     
     

    stmt is not finalized in error or success.

  6. libpurple/purplecontactmanager.c (Diff revision 4)
     
     
     

    I believe it might be better to prepare this outside the loop, and bind/step inside only.

    See lifecycle at https://www.sqlite.org/c3ref/stmt.html

  7. libpurple/purplecontactmanager.c (Diff revision 4)
     
     

    But if stmt preparation is not moved outside the loop, then this one is not finalized in the case of success.

  8. libpurple/purplecontactmanager.c (Diff revision 4)
     
     

    But if stmt preparation is not moved outside the loop, then this one is not finalized in the case of success.

  9. libpurple/purplecontactmanager.c (Diff revision 4)
     
     
     
     
     

    Same here about moving outside loop.

  10. libpurple/purplecontactmanager.c (Diff revision 4)
     
     

    Same here about finalizing on success.

  11. libpurple/purplecontactmanager.c (Diff revision 4)
     
     

    Can move into the only if that uses it.

  12. libpurple/purplecontactmanager.c (Diff revision 4)
     
     

    It's just gpointer.

  13. libpurple/purpletags.c (Diff revision 4)
     
     
     
     

    Can be combined into g_clear_list.

  14. 
      
Loading...