summaryrefslogtreecommitdiff
path: root/feature
diff options
context:
space:
mode:
Diffstat (limited to 'feature')
-rw-r--r--feature/composite/interface-type38
-rw-r--r--feature/composite/list9
-rw-r--r--feature/container/list7
-rw-r--r--feature/doc/list11
-rw-r--r--feature/list16
-rw-r--r--feature/query/list3
-rw-r--r--feature/view/list9
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.