dba module for 5.x missing
| Project: | Demonstration site (Sandbox / Snapshot) |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | smk-ka |
| Status: | closed |
I tested V1.1.2.2 (CVS)
MySQL 5.0.27
PHP 5.1.6
Apache 1.3.37
dba module with latest drupal 5 patch (worked without errors)
Create snapshot gives a list from "show create table access" to "show create table watchdog"
Last reset: never
Last dump: never
In the map files the map "demo" is made, there is no content
I made a page
Back to demonstration site
Last reset: never
Last dump: never
Reset site gives the error: Dump file files/test1/demo/demo_site.sql does not exist.
Last reset: day, date - time
Last dump: never
Nothing is happening.
I tried this a few times.
I found in the files/tmp map a few sql files named yyyy-mmdd-mmss_backup sql.qz. It could not be the sql files from dba, there were no crons in this periode. These file are generated by demo.
My conclusion: the wrong filenames in the wrong map.
Hope this can help the module building
Martin
#1
I hoped that the 5.x update for dba.module was committed earlier. Although I can't see anymore bugs, it seems that dww wants to test the patch some more... (see issue)
The additional downside of this is, that Demo requires another patch for dba to be committed. And I really do not want to fork the dba module.
As long as dba is not publicly available for 5.x I think it's best to allow testing of Demo with a temporary dba.module I'll upload here. Just replace the files of dba with those supplied here (remove extension .txt).
#2
Appropriate .info file.
#3
Thanks, I will test with it
Martin
#4
Provided module works fine for me.
Changed status to reflect this workaround actually works.
--
Stefan Kudwien
http://www.unleashedmind.com
#5
Please do not use the temporarily provided dba.module on productive sites.
The new 5.x version of dba will be available soon.
#6
dba doesn't look to be moving along. :(
Thanks for the attached version. After a bit of version hacking I got your 'adequate' port over there to patch OK, but on debugging, none of the patches or CVS history seemed to show any evidence of dba_auto_backup() ever taking any arguments ... which is why my snapshots were not saving anywhere (as described in the problem above).
I've poked the backup.module before now, and I see a lot of duplication between that and what dba has done ... and what this module is doing too. my ideas on site replication also fall into the same general area :)
I like how demo is small, and only provides the needed UI for what it does. Very useful (although I had hoped it would provide 'branching' or release snapshots that could run independantly of the main site... )
This dependance on dba is a bit unfortunate however. :(
Can't we just steal the three functions we need from it? ;-)
... I'm yet to actually use the module, so let's see how it goes...
.dan.
#7
dba finally released a dev version.
#8
If it takes too long let's just dump dba. Also reduces overall code size if you weren't using any of the other dba functionality.
--
Stefan Kudwien
unleashed mind
#9
#10
I'm not sure if this is 100% this-patch related, but I tried it out today.
The first half went pretty well.
I set up a snapshot, made a config change and went to restore it.
White error page:
- First, I'd suggest that 'watchdog' be excluded from the dump anyway.
- And it seems to be a recursive sorta error - watchdog complaining about itself ...
.. AH. That's probably a known issue with fecking api.module. I hit it when synching a site this weekend. It has a column named 'return' ... which is a reserved word :( Probably not demo.modules fault.
Returning to the site, I saw the errors again, as Drupal warnings.
user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''<div class="php"><code><span class="php-keyword">function</span> <span class="p' at line 1 query: INSERT INTO api_documentation VALUES(84, 'sitesynch_bookmarklets', 'Development', 'function', 'sitesynch_bookmarklets', 'sitesynch/sitesynch.module', 'Display the setup for form-synch bookmarklets.', '<p>Display the setup for form-synch bookmarklets.</p>\n', '<div class="php"><code><span... and more.
HOWEVER it semed to be only the troublesome api.module, and the rest of the site reverted, as far as I can see.
... I'll look deeper and see what the syntax is that's breaking it. I can probably debug the SQL when I look at it. I've done several of these scripts before.
Again - this may not be this module/patches fault directly - but it's a symptom I got on an otherwise mostly-clean site.
#11
What are the reasons we are not just using mysqldump to prepare this SQL?
We can even list the tables by name if we have to deal with prefixes etc. All the rebuild-by-hand seems a bit flakey.
#12
I've been playing around with the the command line tools, they work (even for Postgres), but they force you to have safe_mode disabled. I'd definitely include these as an option, but still have script generated dumps as a fallback.
That's why decided to rip some more code from the phpMyAdmin project, the central function is now 100% identical. So, if you don't have any problems dumping with phpMyAdmin, you shouldn't have either with demo module.
To test, grab a clean dev copy (or CVS checkout) and apply the attached patch.
#13
Looks great!
However, can't we try to execute mysqldump now and fallback to the dumping code of phpMyAdmin if it could not be invoked?
There is a minor coding-style issue: (there might be some tabs instead of spaces)
<?php+ // Include database specific functions
+ switch ($db_type) {
+ case 'mysqli':
+ $engine = 'mysql';
+ break;
+ default:
+ $engine = $db_type;
+ break;
+ }
?>
#14
Found an issue: The generated SQL dump file is saved as ISO-8859-1 instead of UTF-8. Are we able to save sql files in UTF-8?
#15
Let's do this in a second step.
How can you say? From my tests this is not the case.
Attached patch has spaces instead of tabs.
#16
#17
Sorry, my fault. I was accidently looking at an old version.
However, I've just tried to import a rather huge dump (Drupal test site) containing data for API module, that failed.
API module stores function signatures (some with single quotes in the value) in the table api_function. The import broke somewhere in that table. A quick comparison of line counts tells that there are 428 datasets missing.
Attached is the complete dump of this table.
Additionally, I'm adding the greatest non-empty dataset in the table api_function at the end of the file.
#18
Interestingly, phpMyAdmin imports the same dump file without any errors. Maybe they are using some special character escaping for imports, too?
#19
Yes, import was broken, too. I think I've got it working now and committed
http://drupal.org/cvs?commit=81167: Removed dependency on dba module
http://drupal.org/cvs?commit=81171: Fixed db import. Excluding watchdog table from dump/restore.
#20