|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
Re: Inserting with a column that uses auto_increment
Date: Tue Aug 14 2007 - 18:11:49 EDT
Graham Reitz wrote:
>
> I also stated mysql++ has many very nice features.
What's wanted here isn't more praise, but more ideas.
> 1) Macros are very difficult to debug.
Yes, that's well understood. If you'll read the Wishlist, you'll see that the proposed SSQLS replacement already addresses this.
> I had to go through a ssqls 50 columns in length and eliminate each
> column one by one to figure out what the offending type was.
Learn binary search, love binary search.
> Compile time errors are always more desirable than segmentation faults.
None of what I wrote was related to your uninitialized variable segfault issue. That's a pure bug report, and is totally fine.
We're talking about design errors here, not plain ol' bugs. The distinction is this: if fixing it requires changing an interface, it's a design error. I can fix this problem inside the ColData class itself. It's just a bug.
> If blob types need to be initialized ahead of time the compiler should
> indicate that requirement, not a seg. fault.
No, a default-initialized ColData should have reasonable defaults, so when you access it, it doesn't blow up on you.
> 2) It is common to have tables > 50 columns in length.
Sigh...proof by assertion.
The question was, "what kind of design requires this?" The only way you can answer that to my satisfaction is to show me your schema, and defend it. If you're not willing to do that, that's fine. I will just go on believing that it's probably wrong, due to lack of evidence to the contrary.
> 3) The need to use the MYSQLPP_SSQLS_NO_STATICS macro is undesirable
....and you would do what instead?
> 4) Using namespaces to workaround an issue with auto increment fields
You must not have understood my reply to Jim, or didn't read it. Go read it [again].
It tells you that you can have two SSQLSes in the same namespace for the same table, with different C++ structure names.
> 5) Exceptions might be overused, depending upon the author's definition
> of what is an exceptional circumstance.
You're acknowledging that this is a taste issue, so the only change that can satisfy more than just yourself would be something like a pluggable exception policy framework. And if that's the solution, I have only one response: patches thoughtfully considered.
> Any library even the c++ standard libraries should be able to and eager
> to receive criticism from time to time. It is not a personal attack in
> any sense. I am sorry if it seemed that way.
No, actually, plain old criticism never receives a warm welcome, not anywhere, from anyone. This fact of human interaction is so basic that most people figure it out before they leave elementary school.
What is welcome is *constructive* criticism.
Plain old criticism is "X sux." Constructive criticism is "X sux, but you can fix it with Y," where Y is more than just a buzzword. In the context of MySQL++, Y needs to be an actual design, if not a code patch.
The closest thing to constructive criticism you've offered so far amounted to "fix it with RAII". This is about as helpful as answering "wash more often and stop copulating" when asked what to do about the African health crisis.
If you want to be helpful, you're going to have to offer more than just vague prescriptions.
-- MySQL++ Mailing List For list archives: http://lists.mysql.com/plusplus To unsubscribe: http://lists.mysql.com/plusplus?unsub=lists@pantek.comReceived on Tue Aug 14 21:24:36 2007
This archive was generated by hypermail 2.1.8 : Sun Oct 07 2007 - 10:02:58 EDT
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |