>>> 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."
> It wouldn't be hard to regenerate these headers from the Perl scripts
> after installing the package. Or, install from source, or build your
> own package.
Unfortunately recompiling mysql++ isn't really an option, as most of our
centralised production servers are maintained by people who will only
install system libraries from certified binaries, for support reasons.
Annoying I know, but almost all enterprise environments work the same
way. It'd be fine on my development PC, but if I can't run it on a
>>> Any possibility then of doing what Boost does and use #ifdefs to
>>> hide the extra definitions, so you can just #define something
>>> before including the header to get the number of parameters you
> Possible, but that would mean seeking out and installing those old
> compilers to test that the #ifdef fix does in fact prevent the
> compiler breakage. There are at least two I know of, and neither is
> particularly easy for me to dig up.
Given that #ifdef has been around for a long time, I think it would be
unlikely to cause problems. If you don't have those old compilers handy
then you mustn't be testing new releases against them, so that level of
backwards compatibility can't be that important :-P
> Besides which, it's not unreasonable that some compilers choke on
> ssqls.h files that define many more fields. The size of ssqls.h goes
> up superlinearly as a function of the number of fields you ask it to
> generate. (The curve appears exponential, but my curve fitting
> program is being balky so I can't be sure.) At 100 fields --
> quadruple the default -- ssqls.h is about 12 times larger!
> 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.
>> I reckon the answer will be "show me a proper reason you need more
>> than 25 fields in a table" combined with "wait for SSQLS v2" and
>> "but if you give us a working patch"... etc. Otherwise, vertical
>> partition is your new bestest friend!
> All good answers! :)
Well for one, I don't have any control over the source system. I'm not
designing my own database like this, I have to read data from somebody
else's system with very wide tables.
Secondly, I'm not entirely sure how you would come up with an
alternative design for that database. The particular table giving me
problems records information about published material (say a book in a
library.) You have columns for the title, publisher ID, date published,
country published, language, number of pages, and so on. There are
almost 40 fields that have a one-to-one relationship with the item.
Granted I'm no database designer, but to me a wide table seems perfectly
suited to this kind of data.
At any rate this system needs to be finished in a couple of days, so
unfortunately I don't have enough time to do up any patches or wait for
SSQLS v2, so I'll have to try another library this time - but thanks for
all your help!