Start tracking ODB change development in git

7 files changed, 93 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?
diff --git a/feature/container/list b/feature/container/list
new file mode 100644
index 0000000..17b1d8a
--- /dev/null
+++ b/feature/container/list
@@ -0,0 +1,7 @@
+- Ability to define custom indexes on container values
+
+  Currently we only support id and index but there is no good reason (other
+  than complexity) why we shouldn't support values as well. Will need to
+  support composite values.
+
+  See email from marcos.glez@gmail.com/22-Aug-2014.
diff --git a/feature/doc/list b/feature/doc/list
new file mode 100644
index 0000000..addc545
--- /dev/null
+++ b/feature/doc/list
@@ -0,0 +1,11 @@
+? Doxygen documentation for runtime libraries
+
+  Have .doxyfiles for libodb and libodb-oracle in vault/doxygen/
+
+  Follow up with mne@qosmotec.com if found useful.
+
+- Show how to use stored procedures in each DB.
+
+  Also some DBs distinguish between procedures and functions. Need
+  to figure out and show that as well. And test. See MySQL as an
+  example.
diff --git a/feature/list b/feature/list
new file mode 100644
index 0000000..18629dc
--- /dev/null
+++ b/feature/list
@@ -0,0 +1,16 @@
+* Documentation: doc/
+* Composite value: composite/
+* Container: container/
+* Query: query/
+* View: view/
+
+- Mass UPDATE
+
+  This could be very useful in data migration code. In fact, need to
+  add an example in the manual when this is supported.
+
+! Diagnose lack of default ctor if object used in relationship
+
+  Got two questions on the mailing list about that in one week. Maybe
+  always diagnose lack of public ctor? Maybe with a warning if no
+  relationship? The no_ctor pragma like no_id?
diff --git a/feature/query/list b/feature/query/list
new file mode 100644
index 0000000..4d09312
--- /dev/null
+++ b/feature/query/list
@@ -0,0 +1,3 @@
+- Shortcut query() call for queries that always return one element
+
+  Can be useful for aggregate queries, etc.
diff --git a/feature/view/list b/feature/view/list
new file mode 100644
index 0000000..33024ac
--- /dev/null
+++ b/feature/view/list
@@ -0,0 +1,9 @@
+- Member names for table views
+
+  Currently we have to specify column names as strings in table views queries.
+  There is no way to use view member names. If we support this, then is would
+  also be useful to be able to add members that are not selected but can be
+  used in query conditions (readonly?). Looks like we need a general way to
+  describe a table (and generate query_columns from it).
+
+  See email from frankiegp@libero.it/14-Jul-2014.