On Jan 28, 2010, at 8:50 PM, Adam Nielsen wrote:
>>>> Hmm, okay, that complicates things a bit if I can't rely on a
>>>> machine's package management system to have installed mysql++
>> I'd say it *is* proper for MySQL++ to be installed with its sane
>> defaults. :)
> Well okay, "if I can't rely on the package management system to have installed
> mysql++ with the number of parameters I need."
As Joel pointed out, you don't *have* to use template queries or SSQLS. Those are just
convenience mechanisms. MySQL++ doesn't have problems with large column counts when you
provide the SQL to it, or in dealing with wide replies from the server. The stock
configuration just can't generate such things internally.
> If you don't have those old compilers handy then you mustn't be testing new releases
> against them
You're assuming that I have an instance of every compiler/OS/CPU combination MySQL++
supports, and test on every one of them before releasing. I don't know of any open
source project that works that way. It would be rather impractical, given how many
combinations there are.
Just one f'rinstance, MySQL++ has been used in QNX on custom embedded boxes running
who-knows-what weird embedded CPU. There are probably thousands of combinations within
just that one sub-category.
>> While it's nice to have a compiler that can digest 13 MB of macros in
>> a single gulp, I can't summon up much scorn for one that can't.
> Exactly why you can #ifdef out the bits you don't need. The preprocessor would then
> drop 12.9MB of your 13MB file and the C compiler would be fine. This is exactly why the
> Boost folks do it this way. The default is a sane number of parameters, then you #define
> SOME_VALUE 50 before the #include and hope you have a good compiler.
That depends on the nature of the problem, now doesn't it? Since almost the entire
contents of ssqls.h are preprocessor directives, if the bug in these compilers is due to
overrunning some buffer for holding preprocessor code, it won't matter that some of it is
ifdef'd out. It'll still be megs of macros either way.
Not all compilers call some external preprocessor program as a separate pass. It's often
integrated into the compiler itself, particularly on non-Unix systems.
> There are almost 40 fields that have a one-to-one relationship with the item.
You know, this is the first time someone's actually offered a substantial response to my
challenge to their schema design! I've been using that argument for years.
I *am* willing to be swayed, but every previous time when I've said "show me your schema"
people just go away, and I can't tell whether that's because I won the argument or they
just went away.
If your table's CREATE statement is human-readable (i.e. column names that make sense to
outsiders, etc.) I'd love to see it. You can send it to my email address only, if you
feel it's proprietary information.
> At any rate this system needs to be finished in a couple of days
Why are you arguing about it, then? Did you really expect the library to be changed,
tested, released, packaged and pushed through to your OS's package repository in time for
deployment? Best possible case for that is most conveniently measured in months.
If you want rapid changes, you have to build from source regardless. That's just the
nature of the beast.
> I'll have to try another library this time
If you do, I'd be curious to know what you find. I don't know of another C++ wrapper for
MySQL++ that can generate 40+ column SQL statements for you and is likely to be found in
your OS's package repositories already. If there *is* another, I'd like to know what it