[mdb-dev] mdb-export with -I and -N

[Nirgal <con...@ni...>]

On Friday 27 January 2012 19:32:58 George L. Emigh wrote:
> (...) ran into another problem, wanted 
> to add a prefix to the table names using the -N <namespace> option.
> 
> for -N qp mdb-schema gives:
> DROP TABLE [qp_Customer Table];
> CREATE TABLE [qp_Customer Table]
> 
> which is what I expected, but mdb-export -I mysql -N qp gives:
> INSERT INTO qp`Customer Table` (
> 
> Namespaces is not mentioned in the man pages but is when you run the command 
> without any options, is Namespaces going to be removed?

Ops. My mistake. I just comited a fix regarding namespaces:

$ src/util/mdb-export -I mysql ~/Desktop/uuid.mdb table1I
INSERT INTO `table1` (`test2`, `test`) VALUES ("OK",NULL);
INSERT INTO `table1` (`test2`, `test`) VALUES ("OK",NULL);

$ src/util/mdb-export -I mysql -N qp ~/Desktop/uuid.mdb table1I
INSERT INTO `qp_table1` (`test2`, `test`) VALUES ("OK",NULL);
INSERT INTO `qp_table1` (`test2`, `test`) VALUES ("OK",NULL);

$ src/util/mdb-export -I postgres ~/Desktop/uuid.mdb table1
INSERT INTO "table1" ("test2", "test") VALUES ("OK",NULL);
INSERT INTO "table1" ("test2", "test") VALUES ("OK",NULL);

$ src/util/mdb-export -I postgres -N qp ~/Desktop/uuid.mdb table1
INSERT INTO "qp"."table1" ("test2", "test") VALUES ("OK",NULL);
INSERT INTO "qp"."table1" ("test2", "test") VALUES ("OK",NULL);

Patch is available at:
https://github.com/brianb/mdbtools/commit/7e34078bcc9a7b23ab028db969cdf77c0b283752

> Also I see the sanitize option is gone, will that option to convert spaces 
> to underscores be coming back?  I liked the feature, convert all fields and 
> table names to lowercase would be nice too, but for now I'll just alter my 
> tables after the conversion.

I don't plan to work on sanitizing again (but maybe someone else will).
Non-ascii tables results in duplicate names. For exemple, chinese names will create tables "___" "___". One need to add something to diferentiate them, such as a number:
"___1" "___2".
Then you need to store new names for handling foreign contraints, and so on.
Not trivial at all.
With the proper escape now working, I don't see the point.
Removing spaces from table names after mysql conversion seems a bit out of scope, in my opinion.

Cheers