Using Revisr to sync database between dev and staging, error on pull

– Accidental Double Post –

Hi,

I’m not able to replicate this issue. Pulling manually will likely produce different results unless you use the same pull command used in Revisr.

The way it works right now is that when you do a pull, with the “Import DB when pulling changes” option checked, Revisr will backup your tracked tables, then do a pull with the “-Xtheirs” merge strategy, purposely overwriting the backup we just took (the commit hash of the backup is then stored in the .git/config for use later if needed). Then, Revisr imports the DB and runs the search/replace, etc.

What happens when you try to do it from within Revisr (on the latest version)? Do you get any errors?

Aha! Apparently I was not using the latest version of Revisr. Rookie mistake. My apologies.

Now Revisr reports that it is importing successfully with no errors, but changes to the database are not being reflected on the site I’m pulling to.

For instance I created a new page on my development site, backed up the database with the “Backup Database” button, pushed changes to GitHub, and then pulled those changes to my staging site. Revisr on the staging site reports that it imported successfully, but the new page doesn’t appear.

Any thoughts?

EDIT: Possibly noteworthy, the commit list on the staging site doesn’t offer to “revert database” for commits made with the method above, so it seems like the database isn’t being imported?

Nope, that version was just released tonight ??

Can you paste here or send an email to support@expandedfronts.com with the debug info in the “Help” settings tab?

Also, is it saying it successfully imported the database and giving you an undo link or just saying it pulled the commits?

That might help narrow things down if it’s a configuration issue. Thanks!

Thanks for your continued help on this.

I think this is the info you’re looking for from the help tab (adjusted slightly to remove personal data):

Operating System	Linux
Exec() Enabled	true
Git Install Path	/usr/bin/git
Git Version	git version 1.7.1
MySQL Install Path	/usr/bin/mysql
File Permissions	true
Repository Path	/home/username/public_html/sitename
Repository Status	Click here to view.

I just ran through the process again (back up database button on development -> push changes to GitHub -> pull changes on Staging), and I get the following:

Successfully imported the database. Undo	1 min ago
Pulled #51854d8 from origin/master.	1 min ago
Successfully backed up the database.	1 min ago

I hope this is helpful!

Thanks! Everything looks good here. Can you please confirm if the tracked tables are the same on both servers and as a minimum you’re tracking the “wp_posts” and “wp_postmeta” tables?

Both sites are tracking “All Tables”.

Thanks. Assuming backups and Git is working fine otherwise on both servers, the only way I can see to troubleshoot this would be to check the database files manually after doing a pull. Is there any chance you could try a pull and see if it has the DB from your local in the “wp-content/uploads/revisr-backups/” directory?

I’m thinking the error is likely with the DB side of the import as opposed to the git side of things, as it’ll only even try to import if the pull was successful.

Hi, sorry for the delayed response. I just did another test backup/push/pull and all files in my staging revise-backups folder now have today’s date on them. Furthermore, those .sql files have the updated content in them (I made a page called “Test Page”, and it’s in the revisr_wp_posts.sql).

So the problem is definitely on the db import side of things.

Checking my mysql error log I’m not seeing anything related to this import.

Any insight on where I might look for errors, logs, or debug info?

Manually running the content of the .sql files through phpmyadmin works.

Edit – sorry – I asked for info you already provided. Reviewing.

– Update –

Well it looks like it does have your mysql path, which normally means everything should be working.

Unfortunately right now the most sure fire way to debug the issue would be to run the same command in command line that it’s trying to run during an import, which would look something like this:

/usr/bin/mysql -u 'DB_USER' -p'DB_PASS' DB_NAME --host DB_HOST < /home/username/public_html/sitename/wp-content/uploads/revisr-backups/wp-posts.sql

Just as a side note, over the past few days I’ve been working on refactoring the database functionality to improve the error handling and flexibility, and plan on releasing some of those improvements this week.

Edit: And I replied too quickly!

Is there some way I could pipe all of the php exec output (if any) to a file to see what it says?

One sec

The version downloadable here pipes all the exec output for imports into the main activity log, which should help you debug further. Nothing fancy here, but I do have a more elegant version in the works.

https://github.com/ExpandedFronts/Revisr/archive/sample-debug.zip

Hi,
I’m very sorry to report that I’m not seeing any new errors or log information using that version.

I’m going to try to pull to a different remote environment to eliminate that as the culprit. I’ll report back.