Hi,

Been kinda busy lately, and very slowly catching up.

While reading the svn diffs, I came across:

+ o Some field_list() functions use the do_nothing manipulator, while
+ others use the quote manipulator. Standardize on one. Probably
+ do_nothing will work in all cases, because field names that work
+ as SSQLS member variable names don't need quoting or escaping.
+ But, among the fancier SSQLS features is the ability to use
+ different C++ variable names than the SQL table uses for field
+ names. Is it worth breaking that compatibility?

I can imagine a case where a MySQL table uses a C++ keyword as a field name,
which would require SSQLS to support different names.

- Chris


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Chris Frey wrote:

I'm not proposing dropping that feature of MySQL++.

SQL allows you to have a table with a column called "My Bizarre Field
Name With Spaces In". You'd have to quote that when building SQL
statements, so you'd need MySQL++ to use the quote manipulator for some
of its features to work. The feature allowing the SSQLS structure to
have different data member names than in the SQL table enters the
picture because you'd also need to use that feature to get your _C++_
syntax correct.

All that having been said, is the auto-quoting part a reasonable thing
to support? By taking advantage of that feature of SQL, you're causing
yourself extra work in generating the SQL, and you're making it
difficult to map the SQL schema directly to C++ data structures. So,
what is the likelihood that you'd see such a field in real world code?
One is rather disincented to take advantage of this feature.[*]

Since having the library behave two different ways for one thing is
wrong, we have a choice. That choice hinges on whether there's any
reasonable argument for real-world code needing quoted field names.
[*] By contrast, you're right to point out that there are other reasons
to use the SSQLS feature than just handling fields with spaces in them.
C++ keywords are a good reason. Now, quoting is also useful for
handling column names with SQL keywords, but I don't believe all SQL
databases allow that. Again there's the question of whether or not the
disincentive to take advantage of this fact is strong enough to make it
unnecessary for MySQL++ to bother supporting it.

Keep in mind while weighing all these options, that if we decide we need
quoting, then field names will always be quoted in generated SQL,
always. That rankles me. It's my argument that it won't be needed
99.99999% of the time, yet it will be there 100% of the time.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

One other comment: another option is to use the do_nothing manipulator
by default, but make it an option to build the library so that it always
quotes field names.

It might even be possible to make this a #define, so that different
programs built on a single system could have it either way. That would
work if all of the manipulator uses are in templates defined in header
files.

Bottom line, I think auto-quoting field names is a bad idea as a general
policy.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

On Mon, Jun 27, 2005 at 10:59:09PM -0600, Warren Young wrote:
I've written a C++ framework for interfacing with ODBC drivers that turned
out somewhat similar to mysql++ a couple years ago. (Unfortunately not
open source at the moment.) ODBC has the same feature, and can support
quoting all over the place.

Also, since ODBC is database-independent, you don't know what the quote
character(s) is/are until you ask the driver.

And with some drivers, if you quote a field, the case matters, while
unquoted fields are case insensitive.

I supported field quoting because I wanted to be feature-complete,
and I didn't know what tables and databases I'd have to deal with.
In one of the classes, the programmer could turn quoting on and
off via constructor argument.

I favour API's that are able to handle any data thrown at them. In
this case, I view the field names themselves as data that the application
needs to deal with. If you're writing something like a generic database
GUI application, you don't know what wild characters the user will use
for a field name. And if the underlying database supports it, the user
might expect it.

Some of the Ruby-on-Rails web-programming demos come very close to making
the field names something that you type in once in the MySQL DB admin GUI,
and it appears on the screen as an HTML label, which emphasizes
the idea that field names are data too.

I think it is a worthy feature to support, but optional. Looks like I'm
contrary yet again. :-)

- Chris


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Chris Frey wrote:
I don't think there's a big gulf between our positions. I'm not 100%
opposed to supporting the feature, but just don't see a good reason for
this support to be on by default.

The question, then, is how to effect the ability to turn this feature on?

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw