From: Warren Young
Date: October 24 2006 9:40pm
Subject: Re: Problems with timestamp
List-Archive: http://lists.mysql.com/plusplus/6069
Message-Id: <453E8835.7050705@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 8bit

Королев Илья wrote:
>> That's fine, I couldn't accept it before v3.0 anyway.
> Possibly, we can try to make an unstable branch. And for example 2.2, 2.4, etc 
> will be stable, and 2.3, 2.5, etc will be unstable. In that case, it would be 
> possible to include new features not in 3.0, but earlier.

It has nothing to do with stability.  If it helps you to think about it 
more clearly, the svn repo is our "unstable branch".

v3.0 is for those things that will break end user code, as your proposed 
changes will.

>> 3. Cope with different type systems.  Notice above that I'm using SQL
>> type names.  It should be smart enough to translate those into the
>> proper MySQL++ type names.  Likewise, if I put in, say, time_t, it
>> should be able to figure out the right thing to do there, too.
> 
> Give a more detailed description, please.

I mean that if the XML file contains "sql_timestamp", "TIMESTAMP" or 
"time_t", the parser should be smart enough to realize that these are 
all effectively the same type.  I don't want the type to be copied 
literally into the header file; I want it to be translated intelligently.

>> 5. SSQLS structures should derive from a common base class.  This let
>> you put some useful common code in the MySQL++ library itself, but more
>> importantly, it would let you make methods like Query::insert() into
>> regular methods instead of templates.
> 
> Give a more detailed description (example), please.

What else needs to be explained?  It would be useful if all SSQLSes 
derived from a common base class that lives in the MySQL++ library. 
There's nothing more complicated than that to it.