Author: wyoung
Date: Tue Mar 21 21:09:31 2006
New Revision: 1267
URL: http://svn.gna.org/viewcvs/mysqlpp?rev=1267&view=rev
Log:
Extracted v3.0 feature set from "Future Features" section, and rewrote a
few of the items with that new plan in mind.
Modified:
branches/v2.1-bakefile/Wishlist
Modified: branches/v2.1-bakefile/Wishlist
URL:
http://svn.gna.org/viewcvs/mysqlpp/branches/v2.1-bakefile/Wishlist?rev=1267&r1=1266&r2=1267&view=diff
==============================================================================
--- branches/v2.1-bakefile/Wishlist (original)
+++ branches/v2.1-bakefile/Wishlist Tue Mar 21 21:09:31 2006
@@ -136,44 +136,38 @@
o Add Chris Frey's packarray class?
-Future Features
----------------
-
- These changes are planned for versions after v2.1. If you
- need one of these changes to happen on some particular
- schedule, the best way to ensure it is to start coding and
- provide a patch!
-
-
+v3.0 Plan
+---------
+
+ Version 3.0 is primarily for those changes that will break
+ the ABI. (i.e. removing functions, changing function
+ signatures, etc.) This plan is very tenuous. Some of this
+ could slip to v4.0.
+
+ o Change the unsigned int overloads for operator[] on
+ const_subscript_iterator and its subclasses from unsigned
+ int to a plain int. This should fix the ambiguous overload
+ problems, such as with row[0].
+
+ See the following threads for reference:
+ http://lists.mysql.com/plusplus/4947
+ http://lists.mysql.com/plusplus/4952
+ http://lists.mysql.com/plusplus/4960
+
o Several MySQL++ functions wrap the MySQL C API too literally:
they indicate success by returning 0 instead of true,
- as most other wrapper functions do. Fixing this won't
- necessarily break the ABI, but it should wait for v3.x
- because it could silently break programs.
-
- o Create adaptors for std::bitset, for storing binary data in a
- MySQL table. Make two options available, one for storing
- the return from bitset::to_ulong() in an UNSIGNED INTEGER
- column, and another for storing a larger set of bits in a
- more flexible way, perhaps as a BLOB.
+ as most other wrapper functions do.
o Apply Waba's patch allowing Null<T> fields in SSQLSes:
http://lists.mysql.com/plusplus/5433
- o Row object currently depends on the associated ResUse object
- to stick around through all calls to .at(), because it needs
- the list of field types in the result set to construct
- ColData objects. This means it's not possible to store
- the result of several queries before accessing the data.
- Currently, this is just a documented limitation, but it
- would be nice if there were a clean way to avoid this.
- Obviously you could just copy the type list when constructing
- the Row object, but that seems pointlessly inefficient.
-
- o Define operator<< for Fields, Row, ResUse, etc. In other
- words, there should be a way to get a user-readable version
- of received data without a lot of code. Perhaps use a CSV
- output format, or a mysql(1) one (ASCII grid).
+ o Deprecate sql_create_basic_* They have less functionality
+ and they're no easier to use than sql_create and friends.
+
+ o Consider whether some of the current boilerplate can be
+ made into a base class that all SSQLSes derive from. Some
+ template functions like Query::insert<T> might become regular
+ member functions, taking a reference to the SSQLS base class.
o Abstract all uses of MySQL C API functions into a database
driver class with a generic interface. This is a step
@@ -202,6 +196,36 @@
server types. Imagine a program for importing data from
PostgreSQL and loading it into a MySQL table, for instance.
+
+
+Future Features
+---------------
+
+ These changes are not assigned to any particular version.
+ They could happen at any time. If you want one to appear at
+ some definite date, get coding and provide a patch!
+
+ o Create adaptors for std::bitset, for storing binary data in a
+ MySQL table. Make two options available, one for storing
+ the return from bitset::to_ulong() in an UNSIGNED INTEGER
+ column, and another for storing a larger set of bits in a
+ more flexible way, perhaps as a BLOB.
+
+ o Row object currently depends on the associated ResUse object
+ to stick around through all calls to .at(), because it needs
+ the list of field types in the result set to construct
+ ColData objects. This means it's not possible to store
+ the result of several queries before accessing the data.
+ Currently, this is just a documented limitation, but it
+ would be nice if there were a clean way to avoid this.
+ Obviously you could just copy the type list when constructing
+ the Row object, but that seems pointlessly inefficient.
+
+ o Define operator<< for Fields, Row, ResUse, etc. In other
+ words, there should be a way to get a user-readable version
+ of received data without a lot of code. Perhaps use a CSV
+ output format, or a mysql(1) one (ASCII grid).
+
o manip.cpp uses mysql_escape_string(), which doesn't take the
selected database's character set into account. To do that,
you must use mysql_real_escape_string(), which differs
@@ -229,20 +253,6 @@
object may be able to look up a suitable Connection object
for the manipulators.
- o Deprecate sql_create_basic_* ? They have less functionality
- and they're no easier to use than sql_create and friends,
- so why bother with them? I suppose the code generated
- is a bit smaller, but *really*.... Only possible saving
- grace is if BC++ can compile them due to the macro code
- being shorter. They also don't have the static members,
- mentioned in the previous item.
-
- o Consider whether some of the current boilerplate can be
- made into a base class that all SSQLSes derive from.
- This may have implications for some templates, like
- Query::insert<T>...they might become regular member
- functions, taking a reference to the base class.
-
o MySQL++ handles automatic quoting and escaping differently
for cout and cerr than for Query streams. This should
probably be simplified so that automatic quoting is only
@@ -270,17 +280,6 @@
values. This could potentially break a lot of
infrastructure, though, so do it only with care.
- o Fix the row[0] ambiguity problem. This stems from the fact
- that 0 is an int type, but can fit either of the unsigned int
- or const char* argument types from operator[].
- See the following threads for reference:
- http://lists.mysql.com/plusplus/4947
- http://lists.mysql.com/plusplus/4952
- http://lists.mysql.com/plusplus/4960
- The ideal way to fix it for v3.0 is to make
- const_subscript_container's SizeType an int instead of unsigned int,
- but this has implications for matching the C API.
-
Bug Fix/Maintenance Items
-------------------------
_______________________________________________
Mysqlpp-commits mailing list
[email protected]
https://mail.gna.org/listinfo/mysqlpp-commits
