http://www.perlmonks.org?node_id=1081733


in reply to RFC: Name and/or API for module ("Type::FromData")

After reading this thread immediately thought of sqlt, looked inside, no premade thing :) so off to search I went


aww, zip http://search.cpan.org/grep?cpanid=FREW&release=SQL-Translator-0.11018&string=guess&i=1&n=1&C=0
aww, 3 unrelated http://search.cpan.org/grep?cpanid=FREW&release=SQL-Translator-0.11018&string=best&i=1&n=1&C=4

Although these two caught my eye SQL::Translator::Parser::JSON, SQL::Translator::Schema::Field

Then I switched to searching within sql guess type, sql best type, sql match type

Found DBD::mysql::AutoTypes -- automatically assign parameters' sql type to support old DBD::mysql functionality

found inside

/^$RE{num}{int}$/ ? DBI::SQL_INTEGER : /^$RE{num}{real}$/ ? DBI::SQL_DOUBLE :

then found

https://metacpan.org/pod/DBI#sql_type_cast  $sts = DBI::sql_type_cast($sv, $sql_type, $flags); sql_type_cast attempts to cast $sv to the SQL type

Looking inside SQL::Translator::Schema::Field I see the same thing

use DBI qw(:sql_types); # Mapping from string to sql constant our %type_mapping = ( integer => SQL_INTEGER, int => SQL_INTEGER,

Food for thought I guess :)

So my one idea (best of the bunch) is to stick it in SQL::Translator::Parser::GuessBestCastTypeMatchPerl , base it on SQL::Translator::Parser::JSON, make it take either perl ref or perl string to safe undumper :) ... so that illegal field names are SQL::Translator::Producer problem (not yours)

Another is Data::InferBestGuessSQLSchemaType but pause says Avoid the too-general nouns like Devel, Sys, Text, Data

?? Send a patch to stick it inside Type::Utils making sure that all the keywords are represented in the docs for search purposes, but Type doesn't feel better than Data -- but yeah, patches are hassles :)

So maybe SQL::Abstract::InferSchemaTypesByBestMatchGuessFromPerlData :)

I definitely feel sql/schema/type/infer ought to be in the name some how, and the all the keywords in the  =head1 NAME  ... NAME - Perl extension ...

Replies are listed 'Best First'.
Re^2: RFC: Name and/or API for module ("Type::FromData") ( infer sql best guess cast type match sqltranslator )
by tobyink (Canon) on Apr 10, 2014 at 11:32 UTC

    You can create a sub in Perl called foo*bar. (Yes, including the asterisk.) You can't do it the normal way like this, because that's bad syntax:

    sub foo*bar { return 42; } print foo*bar(), "\n";

    But all is fine and dandy if you quote the name properly (i.e. use symbolic references):

    my $name = "foo*bar"; *$name = sub { return 42; }; print &$name(), "\n";

    Similarly, PostgreSQL is perfectly happy for you to name a column "when". It's just that the syntax of SQL requires you to quote it.

    $ psql tai psql (9.1.13) Type "help" for help. tai=# CREATE TABLE "foo" ("when" varchar, "select" varchar, "update" v +archar); CREATE TABLE tai=# INSERT INTO "foo" VALUES ('a','b','c'); INSERT 0 1 tai=# SELECT * FROM "foo"; when | select | update ------+--------+-------- a | b | c (1 row) tai=# DROP TABLE "foo"; DROP TABLE tai=#

    (For MySQL, the quote character is ` instead of ", though MySQL does have an option to let it speak proper, grown-up SQL.)

    If you're writing code that needs to deal with an unknown database schema, you should always quote SQL identifier names (e.g. table names, column names) because you don't know what kind of crazy stuff is going to get thrown at you.

    use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name
      Quoting retains case, meaning it will have to be quoted when used, which can be quite inconvenient and very confusing.
Re^2: RFC: Name and/or API for module ("Type::FromData") ( infer sql best guess cast type match sqltranslator )
by Corion (Patriarch) on Apr 10, 2014 at 08:00 UTC

    Thank you very much for your research!

    I think illegal names are mostly a problem of the output and/or input, and not of this module, but that is also why I want to move away from producing strings as output myself.

    I'm a bit wary of pulling in the prerequisites of SQL::Translator, for what should be fairly simple functionality. In the long run, maybe the module should just produce a data structure that SQL::Translator can consume. Most likely, that would be something duck-typed to what SQL::Translator::Parser::JSON produces... SQL::Translator::Schema::Field looks like a good target/output interface though!

    From your discussion of names, I think Guess or Infer should be a relevant keyword, and Data and Type are also very relevant. Names are hard :-/