After reading this thread immediately thought of sqlt, looked inside, no premade thing :) so off to search I went
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 ...
In reply to Re: RFC: Name and/or API for module ("Type::FromData") ( infer sql best guess cast type match sqltranslator )
by Anonymous Monk
in thread RFC: Name and/or API for module ("Type::FromData")
by Corion
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |