Ack, flu season, keep those coughs down! :)
My original thinking was simply to replace an obscure exception with
one that was a little more informative. If your ssqls structure and
table (or query) didn't match, I think this would be hard to track
down unless the code threw an exception.
However, populating structures by name would make that symptom
disapear. I've written up a patch to populate SSQLS structures by
column name as a first effort. It seems to pass dtest. Offered below
for consideration:
Index: lib/custom.pl
===================================================================
--- lib/custom.pl (revision 1988)
+++ lib/custom.pl (working copy)
@@ -267,13 +267,15 @@
my $parm_simple = ""; my $parm_simple2c = "";
my $parm_simple_b = ""; my $parm_simple2c_b = "";
my $parm_names = ""; my $parm_names2c = "";
- my $defs = ""; my $popul = ""; my $parmc = ""; my $parmC = "";
+ my $defs = ""; my $parmc = ""; my $parmC = "";
my $value_list = ""; my $field_list = ""; my $equal_list = "";
my $value_list_cus = ""; my $cus_field_list = ""; my $cus_equal_list = "";
my $create_bool = ""; my $create_list = "";
my $cusparms1 = ""; my $cusparms2 = ""; my $cusparmsv = "";
my $cusparms11 = ""; my $cusparms22 = "";
my $names = "";my $enums = "";
+ my $popul = "mysqlpp::value_list_ba<mysqlpp::FieldNames,
mysqlpp::do_nothing_type0> field_list=row.field_list();\n";
+ $popul .= "for(std::vector<std::string>::const_iterator i =
field_list.list->begin(); i != field_list.list->end(); ++i) {\n";
foreach my $j (1 .. $i) {
$parm_complete .= "T$j, I$j, N$j, O$j";
$parm_complete .= ", " unless $j == $i;
@@ -295,8 +297,10 @@
$parm_simple2c_b .= ", " unless $j == $i;
$defs .= " T$j I$j;";
$defs .= "\n" unless $j == $i;
- $popul .= " s->I$j = row.at(O$j).conv(T$j());";
- $popul .= "\n" unless $j == $i;
+ $popul .= " if( (*i) == s->names[O$j]) {\n";
+ $popul .= " s->I$j = row[(*i).c_str()].conv(T$j());\n";
+ $popul .= " continue;\n";
+ $popul .= " }\n";
$names .= " N$j ";
$names .= ",\n" unless $j == $i;
$enums .= " NAME##_##I$j";
@@ -355,6 +359,8 @@
$parmc .= ", " unless $j == $max_data_members;
}
+ $popul .= "}\n";
+
print OUT << "---";
// ---------------------------------------------------
// Begin Create $i
On 12/7/07, Warren Young <mysqlpp@stripped> wrote:
> Drew M. wrote:
> > I had a strange issue that I eventually tracked down to a mismatch
> > between the number of columns included in the results of a select
> > query and the number of columns my SSQLS structure expected.
>
> This problem is touched upon (obliquely) in the user manual:
> http://tangentsoft.net/mysql++/doc/html/userman/ssqls.html#id2899055
>
> > One idea I have to catch this at run-time would be to assert that the
> > number of columns in a result set matched the size of the ssqls
> > structure
>
> No, this just replaces one form of rigidity with another.
>
> What I had planned for SSQLSv2 is that it would populate fields based on
> name, not position in the Row object. Row already knows how to look up
> fields by name, so this is no big trick.
>
> This has many benefits in addition to solving your particular problem.
> See the repository version of the Wishlist for the current plan:
>
> http://svn.gna.org/viewcvs/*checkout*/mysqlpp/trunk/Wishlist
>
> (It's down in the "v3.1 Tentative Plan" section.)
>
> This can be done in the context of the current implementation of SSQLS;
> it doesn't have to wait for SSQLS v2. I only made it part of v2 because
> this release cycle has dragged on long enough already. If a patch
> happened to appear (*cough* *cough*) before I freeze MySQL++ v3.0, I'd
> be rather likely to accept it, or at least riff on it.
>
> --
> MySQL++ Mailing List
> For list archives: http://lists.mysql.com/plusplus
> To unsubscribe: http://lists.mysql.com/plusplus?unsub=1
>
>
