Hi Warren -
Thanks for the insight. I was sure there was a reason that MySQL++ does
things this way, and you're right that the data pull takes longer (in this
case the stored procedure that does the fetching [as well as some other
related queries] takes ~3 seconds total [plus about 2 seconds for the
store_next() calls] compared to the ~1.5 seconds that the SSQLS population
takes [for ~40000 rows out of 100's of millions]).
We had received an optimization request from our users (this code is part of
a GUI). Now that I have a good reason (our management understands the need
to remain flexible w.r.t schema changes) for why this portion of the code
seemed relatively slow, I can look elsewhere for optimization options.
On Tue, May 5, 2009 at 6:06 AM, Warren Young <mysqlpp@stripped> wrote:
> On May 5, 2009, at 12:31 AM, Warren Young wrote:
> SSQLS did behave that way in v2 and earlier, but I changed it in v3.0.0
>> because that ties a program too closely to the DB schema, making it brittle
>> in the face of schema changes.
> I forgot another common gotcha in MySQL++ v2 with SSQLS that the v3 change
> fixes: you no longer have to declare your SSQLS in exactly the same order as
> the DB columns exist in the table.
> The SQL column order is an artifact of the way it was first declared, plus
> the subsequent sequence of ALTER operations. Field order in a C++ structure
> rarely has a need to remain unchanged through time. Field order should be
> in a logically defensible order, not a mere historical record of the patch
> MySQL++ Mailing List
> For list archives: http://lists.mysql.com/plusplus
> To unsubscribe: