Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 0.8.6

Request #15278 Add option to not drop existing tables
Submitted: 2008-12-09 15:23 UTC
From: yunosh Assigned: ifeghali
Status: Closed Package: MDB2_Schema (version CVS)
PHP Version: Irrelevant OS:
Roadmaps: (Not assigned)    
Comments Add Comment Add patch

Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem : 47 - 29 = ?

 [2008-12-09 15:23 UTC] yunosh (Jan Schneider)
Description: ------------ As a follow-up to bug #13608, we need an option to not drop existing tables. At the current state MDB2_Schema is unusable for us personally, since it requires *all* table definitions to be provided in a single schema, breaking modularity. Beside that, it would remove any table in a database that are currently not in the schema, e.g. any tables added by the user manually. IMO this should even be the default behavior.


 [2009-01-31 21:09 UTC] snytkine (Dmitri Snytkine)
I totally agree. It was very frustrating to find out that after the upgrade of this pear package I ran the schema update and all my existing tables were dropped just because in the new definition XML file I only included a couple of new tables. This totally breaks the backward compatibility and if extremely dangerous because I totally did not expect all my tables to just disappear. I used schema update to add a new table to database, so I create a new definition with just one table, then did something like this: $arrPreviousSchema = $hdlSchema->getDefinitionFromDatabase(); $hdlSchema->updateDatabase($arrCurrentSchema, $arrPreviousSchema); Who whould expect the existing tables to be dropped when updateDatabase specifically takes the current schema as the first argument? I think this is the worst pear package upgrade of all times. For me it was like getting a malisious software from a trusted source. How would you feel if you downloaded some software upgrade, run the upgrade on your computer, then notice that upgraded program installed fine but ALL your other programs were deleted
 [2009-01-31 21:22 UTC] snytkine (Dmitri Snytkine)
I think that if someone wants to drop stale tables, then he can do this by hand or it could be an extra option for updataDatabase() But definitely should NOT be the default behavior Breaking existing API is bad, but this is beyond bad!
 [2009-02-19 22:49 UTC] yunosh (Jan Schneider)
Any progress on this? MDB2_Schema is completely unusable due to this behavior at the moment. I just killed a complete database again, because I forgot to check which MDB2_Schema version is installed.
 [2009-02-19 23:39 UTC] ifeghali (Igor Feghali)
I agree with you all folks. Will work on it as soon as posible.
 [2009-02-22 02:12 UTC] ifeghali (Igor Feghali)
@Dmitri: 1) MDB2_Schema is beta. It is *not* guaranteed to be backwards compatible. 2) It is always a good thing to read the change logs when upgrading. 3) updateDatabase() was *not* designed to add new tables to the database. It was originally designed to compare two full schemas and apply the diff. If it wasn't acting like that before, that's because it was malfunctioning. 4) You can always do a "dry run" (disable_query option) before pressing the "red button". I completely understands your frustration. Now, be careful next time and keep the good mod so I can do my job. Best, Igor Feghali.
 [2009-02-22 18:34 UTC] ifeghali (Igor Feghali)
-Status: Open +Status: Closed -Assigned To: +Assigned To: ifeghali
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on by the end of next Sunday (CET). If this was a problem with the website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.