I recently hit an issue when modifying a schema using pt-online-schema-change. I was unable to modify the schema because some of my constraint names were already very long and the mechanism that pt-online-schema-change uses to keep the constraint names unique (prepending an underscore) pushed them over the 64 char limit and thus the initial (new) table creation failed. Looking at the source, I could see a TODO to change the constraint naming mechanism to use something such as UUIDs to avoid potential collisions. Since this approach would also solve my problem, I implemented a patch to do it.
I modified pt-online-schema-change to take a '--uuid-constraints' cli option (default 'false') which if present would use a UUID-derived FK name for the constraints on the new table instead of simply prefixing the old constraint names with underscores. If there is any interest I'm happy to provide the code.
FWIW, the most reliable way to bring this to the attention of the PT developers is to log it as a feature request at https://bugs.launchpad.net/percona-toolkit and attach your patch. You'll have to register an account for yourself at Launchpad, but that's free and easy, and has other uses too.
> I recently hit an issue when modifying a schema using pt-online-schema-change. I was unable to modify the schema because some of my constraint names were already very long and the mechanism that pt-online-schema-change uses to keep the constraint names unique (prepending an underscore) pushed them over the 64 char limit and thus the initial (new) table creation failed. Looking at the source, I could see a TODO to change the constraint naming mechanism to use something such as UUIDs to avoid potential collisions. Since this approach would also solve my problem, I implemented a patch to do it.
> I modified pt-online-schema-change to take a '--uuid-constraints' cli option (default 'false') which if present would use a UUID-derived FK name for the constraints on the new table instead of simply prefixing the old constraint names with underscores. If there is any interest I'm happy to provide the code.
> Regards,
> Morgan
> -- > You received this message because you are subscribed to the Google Groups "Percona Discussion" group.
> To post to this group, send email to percona-discussion@googlegroups.com.
Is there a public repository for the Percona Toolkit?
My patch was against the shipped Perl utility, but it looks like this has been assembled using some kind of build process (to inline dependent modules etc). I guess a patch against the (built) utility isn't much use if that is the case; it would be better to patch against the actual sources.
Thanks,
Morgan
On 11/10/2012, at 5:09 AM, Bill Karwin <bill.kar...@percona.com> wrote:
> FWIW, the most reliable way to bring this to the attention of the PT developers is to log it as a feature request at https://bugs.launchpad.net/percona-toolkit and attach your patch. You'll have to register an account for yourself at Launchpad, but that's free and easy, and has other uses too.
> Regards,
> Bill Karwin
> On Oct 10, 2012, at 12:23 AM, Morgan Pyne wrote:
>> Hi,
>> I recently hit an issue when modifying a schema using pt-online-schema-change. I was unable to modify the schema because some of my constraint names were already very long and the mechanism that pt-online-schema-change uses to keep the constraint names unique (prepending an underscore) pushed them over the 64 char limit and thus the initial (new) table creation failed. Looking at the source, I could see a TODO to change the constraint naming mechanism to use something such as UUIDs to avoid potential collisions. Since this approach would also solve my problem, I implemented a patch to do it.
>> I modified pt-online-schema-change to take a '--uuid-constraints' cli option (default 'false') which if present would use a UUID-derived FK name for the constraints on the new table instead of simply prefixing the old constraint names with underscores. If there is any interest I'm happy to provide the code.
>> Regards,
>> Morgan
>> -- >> You received this message because you are subscribed to the Google Groups "Percona Discussion" group.
>> To post to this group, send email to percona-discussion@googlegroups.com.
> -- > You received this message because you are subscribed to the Google Groups "Percona Discussion" group.
> To post to this group, send email to percona-discussion@googlegroups.com.
Ah, disregard my last email; after creating the a/c on launchpad I can see the bzr repo and information to get the src. Patch forthcoming once I figure it out and learn how to use bazaar :-)
M
On 12/10/2012, at 1:17 PM, Morgan Pyne <mor...@vendhq.com> wrote:
> Is there a public repository for the Percona Toolkit?
> My patch was against the shipped Perl utility, but it looks like this has been assembled using some kind of build process (to inline dependent modules etc). I guess a patch against the (built) utility isn't much use if that is the case; it would be better to patch against the actual sources.
> Thanks,
> Morgan
> On 11/10/2012, at 5:09 AM, Bill Karwin <bill.kar...@percona.com> wrote:
>> Thanks for implementing the patch, Morgan!
>> FWIW, the most reliable way to bring this to the attention of the PT developers is to log it as a feature request at https://bugs.launchpad.net/percona-toolkit and attach your patch. You'll have to register an account for yourself at Launchpad, but that's free and easy, and has other uses too.
>> Regards,
>> Bill Karwin
>> On Oct 10, 2012, at 12:23 AM, Morgan Pyne wrote:
>>> Hi,
>>> I recently hit an issue when modifying a schema using pt-online-schema-change. I was unable to modify the schema because some of my constraint names were already very long and the mechanism that pt-online-schema-change uses to keep the constraint names unique (prepending an underscore) pushed them over the 64 char limit and thus the initial (new) table creation failed. Looking at the source, I could see a TODO to change the constraint naming mechanism to use something such as UUIDs to avoid potential collisions. Since this approach would also solve my problem, I implemented a patch to do it.
>>> I modified pt-online-schema-change to take a '--uuid-constraints' cli option (default 'false') which if present would use a UUID-derived FK name for the constraints on the new table instead of simply prefixing the old constraint names with underscores. If there is any interest I'm happy to provide the code.
>>> Regards,
>>> Morgan
>>> -- >>> You received this message because you are subscribed to the Google Groups "Percona Discussion" group.
>>> To post to this group, send email to percona-discussion@googlegroups.com.
>> -- >> You received this message because you are subscribed to the Google Groups "Percona Discussion" group.
>> To post to this group, send email to percona-discussion@googlegroups.com.
We should probably let one of the PT developers advise you on the best way to design a patch.
Honestly, I'm not sure what is the process for building the PT tools from the individual class files in the lib directory. It appears like the lib class files are appended together to form the PT tools, probably to make the tools more standalone and eliminate complications from @INC and so on.
But I know I've seen at least one occasion where the code under lib didn't match the code assembled into one of the tools under bin (in the same release of PT). As if the code in lib were newer, and slightly refactored relative to the code in the stable tool.
> Is there a public repository for the Percona Toolkit?
> My patch was against the shipped Perl utility, but it looks like this has been assembled using some kind of build process (to inline dependent modules etc). I guess a patch against the (built) utility isn't much use if that is the case; it would be better to patch against the actual sources.
> Thanks,
> Morgan
> On 11/10/2012, at 5:09 AM, Bill Karwin <bill.kar...@percona.com> wrote:
>> Thanks for implementing the patch, Morgan!
>> FWIW, the most reliable way to bring this to the attention of the PT developers is to log it as a feature request at https://bugs.launchpad.net/percona-toolkit and attach your patch. You'll have to register an account for yourself at Launchpad, but that's free and easy, and has other uses too.
>> Regards,
>> Bill Karwin
>> On Oct 10, 2012, at 12:23 AM, Morgan Pyne wrote:
>>> Hi,
>>> I recently hit an issue when modifying a schema using pt-online-schema-change. I was unable to modify the schema because some of my constraint names were already very long and the mechanism that pt-online-schema-change uses to keep the constraint names unique (prepending an underscore) pushed them over the 64 char limit and thus the initial (new) table creation failed. Looking at the source, I could see a TODO to change the constraint naming mechanism to use something such as UUIDs to avoid potential collisions. Since this approach would also solve my problem, I implemented a patch to do it.
>>> I modified pt-online-schema-change to take a '--uuid-constraints' cli option (default 'false') which if present would use a UUID-derived FK name for the constraints on the new table instead of simply prefixing the old constraint names with underscores. If there is any interest I'm happy to provide the code.
>>> Regards,
>>> Morgan
>>> -- >>> You received this message because you are subscribed to the Google Groups "Percona Discussion" group.
>>> To post to this group, send email to percona-discussion@googlegroups.com.
>> -- >> You received this message because you are subscribed to the Google Groups "Percona Discussion" group.
>> To post to this group, send email to percona-discussion@googlegroups.com.
> -- > You received this message because you are subscribed to the Google Groups "Percona Discussion" group.
> To post to this group, send email to percona-discussion@googlegroups.com.
