From #106, thank @CJCombrink
We use PostgreSQL and use UUID as a type for many columns, and as such needed something to handle that in sqlpp11 thus rbock/sqlpp11#491 the custom types mechanism to map the UUID to sqlpp11::text and then internally convert the text fields to boost::uuid and it worked well.
Now with sqlpp23 I can actually get get the library to use boots::uuid directly using --path-to-cpp-types but I need to for each column in each table have the csv mapping set up. A quick tally amount to 74 entries in our mapping.
Is there perhaps a way to handle this a bit better, perhaps I am missing it from the ddl2sqlpp script or writeup to basically state for type UUID use boost:uuid directly?
Suggestion:
I guess what you would need is --path-to-custom-types and the ability to actually map custom types there (instead of just the basic types).
We could extend the mechanism like this:
- unqualified type names like integral would be implicitly assumed to be part of sqlpp.
- qualified types like
boost::uuid would be mapped as a custom type
From #106, thank @CJCombrink
We use PostgreSQL and use UUID as a type for many columns, and as such needed something to handle that in sqlpp11 thus rbock/sqlpp11#491 the custom types mechanism to map the UUID to sqlpp11::text and then internally convert the text fields to boost::uuid and it worked well.
Now with sqlpp23 I can actually get get the library to use boots::uuid directly using --path-to-cpp-types but I need to for each column in each table have the csv mapping set up. A quick tally amount to 74 entries in our mapping.
Is there perhaps a way to handle this a bit better, perhaps I am missing it from the ddl2sqlpp script or writeup to basically state for type UUID use boost:uuid directly?
Suggestion:
I guess what you would need is --path-to-custom-types and the ability to actually map custom types there (instead of just the basic types).
We could extend the mechanism like this:
boost::uuidwould be mapped as a custom type