>>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.