Start tracking ODB change development in git

2 files changed, 47 insertions, 0 deletions

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?