>>in sync/view SQL, i seem to often get bits of SQL that are unnecessary
>>("Index already exists" is pretty common), or has already happened
> If you're getting SQL which causes _errors_ that's a bug. I do know that
> with MySQL it will generate a _few_ (very few, as of 0.84) statements
> which don't actually cause a change. But these don't cause errors. If
> you can give me a recipe for generating SQL that causes errors, that'd be
i'm not quite sure what it is about my database alzabo isnt liking, but
i go through and simply setup some foreign keys and this is produced:
DROP INDEX company___id ON company;
CREATE UNIQUE INDEX company___id ON company ( id );
which causes this error:
.. Can't DROP 'company___id'. Check that column/key exists at ..
the table company currently has the following indexes:
name - unique
id - index
this is from a fresh schema reverse engineer, as i accidentally wiped
the last schema. there were some other errors previously, i'll try and
look through those as they come up.
>>when one changes the backend through something outside of alzabo (which
>>is a very possible situation in many ways), it would be nice to have
>>something to automatically adjust to the changes.
>>maybe by deleting the schema, re-engineering, then recreating all
>>possible relationships given the new structure?
> Yeah, it's basically just reverse engineering. The only problem is that
> for MySQL we can't reverse engineer foreign keys (yet?). What you're
> describing could certainly be done. It's basically reverse engineering +
> preserving information we know can't currently be reverse engineered.
right, and maybe presenting a dump of the elements that have changed or
couldnt be reinstated?
on a related note, anyone up for making the "schema-->perl code to
recreate schema" script? it's a bit much for me, i'm afraid.
From: Dave Rolsky <autarch@ur...> - 2004-10-05 15:27:15
On Wed, 29 Sep 2004 c.alzabo@... wrote:
> i'm not quite sure what it is about my database alzabo isnt liking, but
> i go through and simply setup some foreign keys and this is produced:
> DROP INDEX company___id ON company;
> CREATE UNIQUE INDEX company___id ON company ( id );
> which causes this error:
> .. Can't DROP 'company___id'. Check that column/key exists at ..
This looks like a MySQL bug I've seen before that causes MySQL to
give bad information about indexes. Is this a fulltext index, by any
chance? That seems to be a recurring problem.
I'm sure I've reported this to the MySQL folks before. Take a look at the
output of "SHOW INDEX FROM company" and you'll probably see some mistakes
in the output.
Your guide to all that's veg.