From 1927f6d00ca32101de2554946e8b449efb5977c1 Mon Sep 17 00:00:00 2001 From: Boris Kolpackov Date: Thu, 9 Oct 2014 11:29:38 +0200 Subject: Start tracking ODB change development in git --- feature/composite/interface-type | 38 ++++++++++++++++++++++++++++++++++++++ feature/composite/list | 9 +++++++++ 2 files changed, 47 insertions(+) create mode 100644 feature/composite/interface-type create mode 100644 feature/composite/list (limited to 'feature/composite') diff --git a/feature/composite/interface-type b/feature/composite/interface-type new file mode 100644 index 0000000..a5f61ab --- /dev/null +++ b/feature/composite/interface-type @@ -0,0 +1,38 @@ +Some existing value types (e.g., time_period in Boost.DateTime) do not +provide modifiers and the only way to initialize such types is by passing +everything at once in a constructor. For such types it would be nice to +be able to use another, "interface" type to capture the data and then +use it to initialize the desired type at once. The same logic would +apply to persisting the type in the database. + +In fact, we already can do this via virtual data members just very +awkwardly -- one has to specify the interface type (as virtual member +type) as well as to/from conversion functions (as accessors and modifiers) +for every data member of the target value type. So it seems pretty +straightforward to allow specifying this once for a type. + +We already have a very similar mechanism: extended database type support. +The only difference, really, is that there it is about database types and +here it is about C++ types. + +Tricky stuff: + + * There can still be accessor/modifier expressions at the element + level (will have to compose the calls). + + * Containers could be tricky: for them we require by-reference + access. Yes, containers might not even be supported since we + do simple value and container init in separate functions so + a stack-based temporary won't work. This will probably be ok, + however, since the use-case is to facilittate mapping of existing + composite value types and it is unlikely they will use containers + (or maybe not). + +This will need to be implemented as "for all intents and purposes use this +other type as the composite value type except in two places: when getting +const& from the object and when setting value (std::move()?) to the object." + +Could this be something that's also useful for simple value types? Yes! Real +use case: custom lazy ptr (implements loading in ->). Being able to use +standard lazy ptr as interface type would be useful. Right now have to go +through virtual data members. Not going to work well for templates though. diff --git a/feature/composite/list b/feature/composite/list new file mode 100644 index 0000000..8a9c257 --- /dev/null +++ b/feature/composite/list @@ -0,0 +1,9 @@ +- Interface type for existing composite value types: interface-type + +- Make column prefix for locally-defined composite value types empty + + If a composite value type is defined in a class, then we could make + its table prefix empty by default. This will remove the ugly need to + specify an empty prefix for deleted_data. Of course, if it is used + for several data members, then we will end up generating broken code. + Maybe if it is private and only used for a single data member? -- cgit v1.1