I just added a quick fix that should make the procedure less susceptible to issues relating to bug #23856. To do that, I had to remove the
ORDER BY ordinal_positionbits in all the calls to
GROUP_CONCATover the rows in the
If you include the
ORDER BY ordinal_positionclause, the concatenation result will mess up sometimes. The behaviour can be attenuated somewhat by decreasing value for the
group_concat_max_lenserver variable, but so far, I have not seen a sufficiently large valy of
group_concat_max_lenthat does not display this behaviour.
ORDER BY ordinal_positionclause does not seem change the order. Rows from
information_schema.COLUMNSseem to be ordered by
ORDINAL_POSITIONanyhow. I hope I can rely on that order, as all sorts of trouble are to be expected when the column order of the local table differs from that of the remote table.
I also added some output so you can see what the procedure is doing. Some steps, like getting the remote metadata, take rather long, and I found some output to be helpful.
The updated procedure can be found here in the usual spot at MySQLForge.
The updated procedure does not yet support creating federated tables using a separate
SERVERschema object (see the manual).
Please, try it, and report bugs in the procedure by adding a comment to this blog entry. Thank you!