Support » Plugin: Contact Form DB » Adding a Primary Key–what damage am I doing

  • This is a great plugin. I understand that the date/time stamp is the key and that is usually just fine. I am trying to integrate with another application that was built specifically to deal with Ninja forms and I am trying to re-write the SQL to fit DFDB instead. This will create greater flexibility within the application. One part of the SQL for Ninja is referencing a primary key. What I am doing is adding some thing in my application which will do this:


    This adds the key, it seems to duplicate the purpose of the original, and seems to work well with both Ninja and CF7. Am I doing any damage by adding this. As far as I have noticed all is well but what are the risks?

Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Author Michael Simpson


    I think for now it won’t cause a problem. But I can’t guarantee it will be forward compatible. I have thought about creating a non-timestamp id field. I’m not sure if or when I will do that. It might be safer to name your field something very specific (not id) so that it is unlikely to be the same name I might use.

    Every time that I do a find and replace in the WordPress database when deploying from one environment to another, I end up having a mild error come up that the table “wp_cf7dbplugin_submits” has no primary key.

    I want to run the command cravaus proposed, and have a unique ID, but I don’t want to break the DB or other processes that may rely on the DB when you finally do get around to adding the key.

    What’s your timeframe for adding an ID key for the table?
    We have a number of data cubes that we have built and that rely on these tables, and I don’t want them breaking when you upgrade this table to have a key.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Adding a Primary Key–what damage am I doing’ is closed to new replies.