diff options
authorBoris Kolpackov <>2014-10-09 11:29:38 +0200
committerBoris Kolpackov <>2014-10-09 11:29:38 +0200
commit1927f6d00ca32101de2554946e8b449efb5977c1 (patch)
Start tracking ODB change development in git
9 files changed, 128 insertions, 0 deletions
diff --git a/bug/list b/bug/list
new file mode 100644
index 0000000..ff2bd3e
--- /dev/null
+++ b/bug/list
@@ -0,0 +1,22 @@
+! Copyright update [doc]
+! C++11 support is not trully header only [c++11]
+! Statement name truncation in PostgreSQL
+ There seems to be a limit on the prepared statement name in PG. The result
+ is that the names are no longer unique (statement already exists error).
+ What we can do to help with that is put the statement kind (perists, find,
+ etc.) part at the beginning of the name rather than at the end as we do
+ now.
+ See email from <>/11-Jun-2014.
+- Add noexcept to move construction and assignment [c++11]
+ Without noexcept some code (e.g., swap()) may have to resorts to copy.
+! Command Line Tools required for ODB binary package on Mac OS
+ It seems without them there are no standard headers in /usr/include. Need
+ to test and document.
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
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 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
diff --git a/reference/list b/reference/list
new file mode 100644
index 0000000..570537e
--- /dev/null
+++ b/reference/list
@@ -0,0 +1,13 @@
++ stderr_tracer doesn't trace statement preparation [2.4.0]
+ If a statement is invalid, then it will fail during preparation. However,
+ currently, there is no way to see that statement since stderr_tracer doesn't
+ trace this event.
+ Options:
+ * trace preparation by default - too much info
+ * allow changing behavior at runtime - not thread safe
+ * support via bool flag and make user instantiate - burdensome
+ * support via bool flag and instantiate stderr_full_tracer - code bloat
+ but seems the best option