MySQL and webhooks migration 0002

[Paul Du Bois]

I'm not sure if this should be considered a Transifex issue, a South issue, or a MySQL issue. I almost reported it as a South bug but changed my mind at the last minute. Anyway, in (at least) MySQL 5.0.x and 5.1.x, foreign keys need to be "supported" by an index. If the user explicitly adds an index, MySQL will use that one. It will also not let you drop that index. This is a problem for webhooks migration 0002:

    def forwards(self, orm):
       
        # Removing unique constraint on 'WebHook', fields ['project']
        db.delete_unique('webhooks_webhook', ['project_id'])

        # Changing field 'WebHook.project'
        db.alter_column('webhooks_webhook', 'project_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['projects.Project']))

The call to delete_unique() causes a mysterious MySQL error (I believe they have changed it to something more user-friendly in later releases):

  _mysql_exceptions.OperationalError: (1025, "Error on rename of '.\\tfex\\#sql-27f0_16' to '.\\tfex\\webhooks_webhook' (errno: 150)")

As far as I can tell (having almost zero experience with either Django or South), either South needs to be smarter, or the migration needs to do something like

    def forwards(self, orm):
       
        # Removing unique constraint on 'WebHook', fields ['project']
+       # Remove the foreign key to avoid problems with MySQL; it'll get recreated.
+       db.delete_foreign_key('webhooks_webhook', 'project_id')
        db.delete_unique('webhooks_webhook', ['project_id'])

        # Changing field 'WebHook.project'
        db.alter_column('webhooks_webhook', 'project_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['projects.Project']))

Thoughts? Should I file this as a Transifex bug?

paul

[Apostolis Bessas]

Hi Paul,

Since you are not very familiar with django or south, I will avoid the
technical details, but I will try to give you some hints, should you
want to look it further.

On Wed, May 9, 2012 at 5:19 AM, Paul Du Bois <paul....@gmail.com> wrote:
> I'm not sure if this should be considered a Transifex issue, a South issue,
> or a MySQL issue. I almost reported it as a South bug but changed my mind at
> the last minute. Anyway, in (at least) MySQL 5.0.x and 5.1.x, foreign keys
> need to be "supported" by an index. If the user explicitly adds an index,
> MySQL will use that one. It will also not let you drop that index. This is a
> problem for webhooks migration 0002:
>
>     def forwards(self, orm):
>
>         # Removing unique constraint on 'WebHook', fields ['project']
>         db.delete_unique('webhooks_webhook', ['project_id'])
>
>         # Changing field 'WebHook.project'
>         db.alter_column('webhooks_webhook', 'project_id',
> self.gf('django.db.models.fields.related.ForeignKey')(to=orm['projects.Project']))
>

Let's just say that the above migration tries to change a 1-1
relationship (OneToOneField) to a 1-M relationship (ForeignKey).
Since the migration was generated automatically by south, this is a
south issue in the way it did the generation.

> As far as I can tell (having almost zero experience with either Django or
> South), either South needs to be smarter, or the migration needs to do
> something like
>
>     def forwards(self, orm):
>
>         # Removing unique constraint on 'WebHook', fields ['project']
> +       # Remove the foreign key to avoid problems with MySQL; it'll get
> recreated.
> +       db.delete_foreign_key('webhooks_webhook', 'project_id')
>         db.delete_unique('webhooks_webhook', ['project_id'])
>
>         # Changing field 'WebHook.project'
>         db.alter_column('webhooks_webhook', 'project_id',
> self.gf('django.db.models.fields.related.ForeignKey')(to=orm['projects.Project']))
>

Your patch could work. Can you create a pull request against Transifex
(aat Github) or at least open an issue with your patch?

> Thoughts?

Well, if you plan to use Transifex with MySQL, you should be aware of
https://docs.djangoproject.com/en/dev/ref/databases/#mysql-collation.
The above issue causes problems with translation strings and, as a
result, MySQL is not supported. That said, if you can live with that
issue, there should be no other problems using MySQL.

For the record, PostgreSQL is the preferred RDBMS for Transifex and
the one we use as well.

Regards,
Apostolis



--
Apostolis Bessas
Systems Engineer

https://www.transifex.com/

[Paul Du Bois]

Hi Apostolis; thanks for the quick response.

On Tue, May 8, 2012 at 11:34 PM, Apostolis Bessas <mpe...@transifex.com> wrote:
> Let's just say that the above migration tries to change a 1-1
> relationship (OneToOneField) to a 1-M relationship (ForeignKey).
> Since the migration was generated automatically by south, this is a
> south issue in the way it did the generation.

Oh! I didn't realize that the 000xx_ files could be automatically created
by South. I'll definitely file a bug with them then.

> Your patch could work. Can you create a pull request against Transifex

> (at Github) or at least open an issue with your patch?

Sure. Is there a stable branch somewhere that I can track for our
deployment? We plan on using XLIFF, and since that support is somewhat new
in Transifex I expect we may have a trickle of patches to contribute back.

In github I saw tags for most of the stable releases (but notably not for
the most recent 1.2.1 release), and the install docs at
http://help.transifex.com/server/install.html say "Note: that this
repository does not have the branched stable versions which exist only in
the transifex-stable repository." I wasn't able to find the
transifex-stable repo, but maybe that's an old reference to bitbucket?


Also: is this list appropriate for questions about administering and/or
configuring Transifex?

Thanks,
Paul

[Apostolis Bessas]

Hi Paul,

On Wed, May 9, 2012 at 10:24 PM, Paul Du Bois <paul....@gmail.com> wrote:
>> Your patch could work. Can you create a pull request against Transifex
>> (at Github) or at least open an issue with your patch?
>
> Sure.  Is there a stable branch somewhere that I can track for our
> deployment?  We plan on using XLIFF, and since that support is somewhat new
> in Transifex I expect we may have a trickle of patches to contribute back.
>

That would be great! The repository is at
https://github.com/transifex/transifex.

> In github I saw tags for most of the stable releases (but notably not for
> the most recent 1.2.1 release), and the install docs at
> http://help.transifex.com/server/install.html say "Note: that this
> repository does not have the branched stable versions which exist only in
> the transifex-stable repository."  I wasn't able to find the
> transifex-stable repo, but maybe that's an old reference to bitbucket?
>

We recently moved the repositories to github and it seems we have
missed fixing that part of the docs. I will do it now. The github repo
is the only repo for Transifex now.

>
> Also: is this list appropriate for questions about administering and/or
> configuring Transifex?
>

Sure. But you might be interested to find us in IRC, as well, on
channel #transifex.