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 +++++++++ feature/container/list | 7 +++++++ feature/doc/list | 11 +++++++++++ feature/list | 16 ++++++++++++++++ feature/query/list | 3 +++ feature/view/list | 9 +++++++++ 7 files changed, 93 insertions(+) create mode 100644 feature/composite/interface-type create mode 100644 feature/composite/list create mode 100644 feature/container/list create mode 100644 feature/doc/list create mode 100644 feature/list create mode 100644 feature/query/list create mode 100644 feature/view/list (limited to 'feature') 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. -- cgit v1.1