![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
So my question is: Do MySQL++ have a limitation so it only works with one actice Connection object at a time, or do I have to do something special to make it work with several active Connection objects? |
#3
| |||
| |||
|
|
So my question is: Do MySQL++ have a limitation so it only works with one actice Connection object at a time, |
|
And another question: Do you think that it would be more efficient to store inserts + updates in for example a local file, and not send these queries to the database until after the mysqlpp::ResUse object is deleted. |
#4
| |||
| |||
|
|
Byrial Jensen wrote: So my question is: Do MySQL++ have a limitation so it only works with one actice Connection object at a time, If it does, it's considered a bug. Patches thoughtfully considered. |
{|
And another question: Do you think that it would be more efficient to store inserts + updates in for example a local file, and not send these queries to the database until after the mysqlpp::ResUse object is deleted. Probably not. If anything, I'd make the second database local, and do your final analysis there. It sounds like both databases are remote, in which case your bottleneck is the bandwidth of the link to the database. Unless you've got serious pipe, your disk bandwidth will be a lot higher. |
#5
| |||
| |||
|
|
Warren Young wrote: Byrial Jensen wrote: So my question is: Do MySQL++ have a limitation so it only works with one actice Connection object at a time, If it does, it's considered a bug. Patches thoughtfully considered. Thanks to Warren Young and Earl Miles for the replies. I don't have a patch, but I do have a very much cut down program to demonstrate the problems. When I run the program below with the cur table from the database dump found at http://download.wikimedia.org/wikipe...r_table.sql.gz, I get an abort in check_len() which seems to indicate that data returned from ResUse::fetch_row() have been changed. I suspect that this may be due to a mysql++ bug. It may of course also be due to misunderstandings on my side. If so, please tell me what's wrong with the program. When run with valgrind, I get thousands of invalid read errors. All about reads inside blocks previously free'd by the ColData_Tmpl<mysqlpp::const_string> destructor. Like this one: |
#6
| |||
| |||
|
|
From looking this over, I think your problem might be string manipulation. const char *text = row[1]; I'm not sure row[] is guaranteed to return a null terminated string. Without a null terminator, strlen() is guaranteed to fail and fail badly. I believe what you really want is this (slightly longer than it has to be for clarity): std::string tempString = row[1]; const char *test = tempString.c_str(); |
#7
| |||
| |||
|
|
const ColData operator [] (size_type i) const; This returns a temporary, which disappears after that line of code. You need to make a copy for yourself. |
#8
| |||
| |||
|
|
Note that ColData provides casting conversions, so you can cast that data to std::string, int, long, etc, and ColData will try to make the conversion for you. The temporary will still disappear though, so making your own copy is likely the most efficient method. |
#9
| |||
| |||
|
|
On Wed, May 25, 2005 at 11:37:07AM -0700, Earl Miles wrote: From looking this over, I think your problem might be string manipulation. const char *text = row[1]; I'm not sure row[] is guaranteed to return a null terminated string. |
|
Yep, Earl is on the right track. See the declaration of operator[] in row.h: const ColData operator [] (size_type i) const; This returns a temporary, which disappears after that line of code. You need to make a copy for yourself. |
#10
| |||
| |||
|
|
I don't know if it is considered a bug that you cannot write const char *text = row[1]; |

|
but even if it isn't, it might be an idea to warn about the construction in the manual. |
![]() |
| Thread Tools | |
| Display Modes | |
| |