2014-09-21 16:30 GMT+02:00 Hugues Peccatte hugues.peccatte@gmail.com:
2014-09-21 12:20 GMT+02:00 Marc Delisle marc@infomarc.info:
Le 2014-09-20 21:05, Marc Delisle a écrit :
Hi Hugues,
I have not looked deep into this logic, so it seems that you've become the expert here in these matters.
Taking into account that the current master is not acceptable for a 4.3.0-alpha release, I see a few choices:
- remove the mb modifications from the import logic
This one would be the easiest.
This one isn't possible. Even with undoing all modifications in this function, the execution is too long.
- remove the current parser from the import logic, therefore removing
support for things like a custom delimiter and probably other things (import of compressed files?)
The issue isn't about compressed files. I tried to import the SQL into your zip file: it was too long…
- delay 4.3.0 until we find the correct solution with mb
I don't know the delay to find a solution, so not sure that would be enough.
We could also add another (!) custom option in the import dialog: multi-byte or not.
This might be possible… I'll do some tests about choosing the PMA_String* to use.
So, this is not possible either.
The multi-byte way is the more correct one for importing files with multi-byte characters, but simply does not work for big files (10 to 15 times slower). So by default, the option could be set to not use the multi-byte way.
A user with a big multi-byte file would have a problem, unless she is allowed to set the PHP execution time limit to huge values (which not many sysadmins will allow unless they want their shared server to perform badly).
-- Marc Delisle | phpMyAdmin
Thanks for your feedback.
Hugues.
I still try to find the greedy part of the script.
Hugues.