Your python script does store internally the information for columns being the pk.
ddlPrimaryKey = pp.Group(
pp.CaselessKeyword("PRIMARY") + pp.CaselessKeyword("KEY")
).setResultsName("isPrimaryKey")
What would be amazing to write this information into the script generated header under the name is_primary_key :
struct TabFoo_ : public ::sqlpp::name_tag_base {
struct Id : public ::sqlpp::name_tag_base {
SQLPP_CREATE_NAME_TAG_FOR_SQL_AND_CPP(id, id);
using data_type = ::sqlpp::integral;
using has_default = std::true_type;
using is_primary_key = std::true_type;
};
using has_default = std::false_type;
for all other non pk columns.
For me PK is valuable information as a sqlpp23 user. How to you see it as a library owner? Worth implementing it or are there reasons against I do not see?
Your python script does store internally the information for columns being the pk.
What would be amazing to write this information into the script generated header under the name
is_primary_key:for all other non pk columns.
For me PK is valuable information as a sqlpp23 user. How to you see it as a library owner? Worth implementing it or are there reasons against I do not see?