Королев Илья 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.
