Bug #37709 | Forward Engineer SQL Alter script has erroneous contents when no changes made | ||
---|---|---|---|
Submitted: | 28 Jun 2008 6:37 | Modified: | 20 Feb 2009 16:19 |
Reporter: | Ken Zo | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Workbench | Severity: | S2 (Serious) |
Version: | 5.0.23 OSS rev 3198 | OS: | Windows (XP SP2) |
Assigned to: | Alexander Musienko | CPU Architecture: | Any |
Tags: | forward engineer sql alter, forward engineer sql create, no changes |
[28 Jun 2008 6:37]
Ken Zo
[30 Jun 2008 8:27]
Valeriy Kravchuk
Thank you for a bug report.
[19 Jul 2008 21:27]
Ken Zo
I see that the status is now "QA review." Can you tell me when a fixed version might be available? The bug renders Workbench unusable to me for modifying an existing database. If I could try a fixed version before the next release, I would like that, so I could try it against my full model and confirm for you that the bug is fixed for more data other than the smaller test data I provided to you.
[27 Jul 2008 16:20]
Valeriy Kravchuk
Bug #38391 was marked as a duplicate of this one.
[12 Aug 2008 22:00]
Ken Zo
Is there any possibility of knowing when this bug will be fixed? 5.0.24 was finally released today and I see the bug is still open.
[14 Aug 2008 14:10]
Johannes Taxacher
sorry for the delay, we're still inspecting this further ...
[23 Oct 2008 1:51]
Frank Quosdorf
Is there any progress on this bug? It troubled me after not having worked on a model. I had the original model (sql) committed to my project repository a month ago. Yesterday, I applied only a minor change to the model and went via Engineer Alter. I was puzzled by the number of changes found. So, I spent time figuring out what went wrong with the originally committed model. Turned out, nothing was wrong, it's just this bug. This really brings risk to any development cycle.
[2 Dec 2008 17:31]
Ken Zo
Any progress here? This bug renders Workbench OSS pretty unusable, since you cannot rely on the Forward Engineer SQL Alter command, and thus cannot depend on Workbench OSS for updating an existing model.
[13 Feb 2009 12:01]
Frank Quosdorf
now, this bug, together with bug #42266, develops into a dreadful combination as one either needs to live with having unreasonable alter scripts produced (bug #37709) or a complete failure of alteration (bug #42266). This became obvious when I decided to no longer wait for this bug (bug #37709) to be fixed but to create a new project from my latest schema file. First, everything looked fine (except for having to create all new diagrams). But, after adding new fields of type DOUBLE by just "copying" the same declaration from other fields (in fact, I just took the declaration suggested by Workbench), the alteration failed as reported in bug #42266. When manually adding (15,2) to the DOUBLE declaration, the alteration worked as expected, but Workbench again wants to create a new alter script, even when forward engineering against a new and unchanged schema file. This is dreadful when trying to automate the deployment of database alterations. So, I'm back to square one. Is there a chance that this bug gets fixed any time soon?
[16 Feb 2009 15:10]
Johannes Taxacher
this issue has been fixed. The provided document contains some errors though. The Procedure objects have faulty parameter-child-objects in the internal GRT tree. This was caused by another bug that has been fixed in the meantime - but in ther remainders of the bug are still present in saved document. to "clean" the procedure-objects just open them once and to some "fake-editing" (enter a space and delete it again) so that the parser runs throught the routine code and corrects the object. if this is done the fwd.Eng. ALTER does create empty output. fix will be in 5.0.30
[20 Feb 2009 16:19]
Tony Bedford
An entry was added to the 5.0.30 changelog: The Forward Engineer SQL ALTER Script wizard produced an erroneous script. If Forward Engineer SQL CREATE Script was used to generate a script and this was then used as an input to Forward Engineer SQL ALTER Script, without having made any changes to the model, then an ALTER script with no changes should be produced. However, the ALTER script showed many changes, even though no changes had been made to the model.