From: Warren Young Date: January 29 2010 3:31pm Subject: Re: How to do a large template query? List-Archive: http://lists.mysql.com/plusplus/8879 Message-Id: <4B2E3C45-CEA0-4790-8F7B-B5DD34A22F1D@etr-usa.com> MIME-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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++ >>>> properly. >> I'd say it *is* proper for MySQL++ to be installed with its sane >> defaults. :) >=20 > 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. >=20 > 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.=20 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 = is.=