diff options
| -rw-r--r-- | bug/list | 22 | ||||
| -rw-r--r-- | feature/composite/interface-type | 38 | ||||
| -rw-r--r-- | feature/composite/list | 9 | ||||
| -rw-r--r-- | feature/container/list | 7 | ||||
| -rw-r--r-- | feature/doc/list | 11 | ||||
| -rw-r--r-- | feature/list | 16 | ||||
| -rw-r--r-- | feature/query/list | 3 | ||||
| -rw-r--r-- | feature/view/list | 9 | ||||
| -rw-r--r-- | reference/list | 13 |
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 <abellina@gmail.com>/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 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. 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 |