Phew. It looks like our site is back online, and in a way, better than before. It took some time for DNS changes to propagate, which is why despite changes on the server, some queries still ended up on the new thaiopensource.org server. >From now on, the libpqxx site is http://pqxx.org/ (or www.pqxx.org if you prefer). The thaiopensource.org URLs will no longer work, but on the bright side, they are also no longer needed. Jeroen
On Thu, May 31, 2007 14:17, Trigve Siver wrote: > I mean if there is some diffrence using pqxx Transaction.exec() and > pqxx::absolute_cursor. AFAIK cursor read results "on demand" while > Transaction.exec() > return whole result for executed query. Is it true? Can be there some > performance gain when using cursors? Ah, so it's not really about absolute_cursor but about cursors in general. You understood correctly. While a cursor only returns chunks of the work, and only when you ask for them, transaction_base::exec() simply reads the whole result set at once. When talking purely about the overall speed it takes to retrieve all your results, and in a normal program, a cursor will always be slower than exec(). Don't complicate your code with cursors if you don't need to! So why do we have cursors at all? They make sense in many cases: * If your result set can be huge, and you only look at one row at a time, there's no reason to keep the entire result set in memory. With a cursor you can download and process just one chunk at a time. * If you want to give quick first results, and it takes too long to get the whole result set, use a cursor to retrieve and process a bit of your data relatively soon. * If you want to give regular progress reports, e.g. a progress bar, on large result sets, break them up into chunks with a cursor.(Continue reading)
BTW, link to old site is still given in documentation: http://pqxx.org/devprojects/libpqxx/doc/2.6.9/html/Reference/ (see bottom of page) Bart Samwel wrote: > Anyway, I suspect that you'll > have to set a nonnoticer on the connection, something like: > > conn.set_noticer std::auto_ptr<pqxx::noticer> (new pqxx::nonnoticer)); Thanks. I finally (<blush>) got around to trying this... funny thing is, I still get the printouts that begin with "+ INSERT INTO..." when the code runs. When the connection object is created, its noticer is null, and then after the set_noticer call, the noticer is the NONnoticer I gave it. So the auto_ptr stuff should be working. Actually, if the default value of m_Noticer's contents is null, then those "+ INSERT" printouts are definitely not caused by a noticer. I've been grepping around for the right print statement in both pqxx and libpq, but haven't found it yet. Ideas? -- -- Curran Schiefelbein
Curran Schiefelbein wrote: > BTW, link to old site is still given in documentation: > http://pqxx.org/devprojects/libpqxx/doc/2.6.9/html/Reference/ > (see bottom of page) > > > Bart Samwel wrote: > > Anyway, I suspect that you'll >> have to set a nonnoticer on the connection, something like: >> >> conn.set_noticer std::auto_ptr<pqxx::noticer> (new pqxx::nonnoticer)); > > > Thanks. I finally (<blush>) got around to trying this... funny thing is, > I still get the printouts that begin with "+ INSERT INTO..." when the > code runs. > > When the connection object is created, its noticer is null, and then > after the set_noticer call, the noticer is the NONnoticer I gave it. So > the auto_ptr stuff should be working. > > Actually, if the default value of m_Noticer's contents is null, then > those "+ INSERT" printouts are definitely not caused by a noticer. > > I've been grepping around for the right print statement in both pqxx and > libpq, but haven't found it yet. Ideas? Nope, I'm puzzled! My grepping doesn't yield anything else... Perhaps libpq prints this stuff when it runs in some kind of debug mode? Otherwise I wouldn't know...(Continue reading)
Bart Samwel wrote: > Nope, I'm puzzled! My grepping doesn't yield anything else... Perhaps > libpq prints this stuff when it runs in some kind of debug mode? > Otherwise I wouldn't know... > > Cheers, > Bart > It occurs regardless of whether you compile Debug or Release (both packages). It doesn't matter that much. I'm the only one who looks at the output (so far). Thanks anyway. -- -- Curran Schiefelbein
On Sat, June 9, 2007 04:46, Curran Schiefelbein wrote: > Bart Samwel wrote: >> Nope, I'm puzzled! My grepping doesn't yield anything else... Perhaps >> libpq prints this stuff when it runs in some kind of debug mode? >> Otherwise I wouldn't know... > It occurs regardless of whether you compile Debug or Release (both > packages). There's no printing of anything in libpqxx, but libpq has two output channels that I know of: 1. The noticer, which should shut up when it's the nonnoticer. Could always be a bug there... Lifetime management problem maybe? 2. Trace output. Unless you call the connection's trace() function, that shouldn't happen. And it spews a lot more than just a few statements. Jeroen
On Sat, June 9, 2007 04:46, Curran Schiefelbein wrote: > Bart Samwel wrote: >> Nope, I'm puzzled! My grepping doesn't yield anything else... Perhaps >> libpq prints this stuff when it runs in some kind of debug mode? >> Otherwise I wouldn't know... > It occurs regardless of whether you compile Debug or Release (both > packages). There's no printing of anything in libpqxx, but libpq has two output channels that I know of: 1. The noticer, which should shut up when it's the nonnoticer. Could always be a bug there... Lifetime management problem maybe? 2. Trace output. Unless you call the connection's trace() function, that shouldn't happen. And it spews a lot more than just a few statements. Jeroen
there doesn't seem to be a 'reconnect()' in
pqxx::connection_base. What is the best way to
explicitly force connections to reconnect (as in the
case where the db has failed over to a slave, and dns
has been updated to make the slave the new master)?
Gary
____________________________________________________________________________________
Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool.
http://autos.yahoo.com/carfinder/
Hello,
The following program crashes when I run it (I have marked where):
-------------------------------------------
#include <iostream>
#include <string>
#include <pqxx/pqxx>
class ServerContext
{
private:
pqxx::connection m_conn;
public:
ServerContext();
bool createSession();
bool touchSession(const std::string& id);
};
ServerContext::ServerContext() : m_conn("")
{
std::cout << "Foo 1" << std::endl;
m_conn.prepare("addsess", "INSERT INTO sessions (id,addr) VALUES \
($1,$2)");
std::cout << "Foo 2" << std::endl;
m_conn.prepare("touchsess", "UPDATE sessions WHERE id=$1 SET \
(Continue reading)
Hi Jan,
Could you try the latest SVN version of libpqxx? I remember that
something was fixed in this region recently, and I'm not sure if that
fix is in 2.6.9.
Cheers,
Bart
Jan Danielsson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hello,
>
> The following program crashes when I run it (I have marked where):
>
> - -------------------------------------------
> #include <iostream>
> #include <string>
> #include <pqxx/pqxx>
>
>
> class ServerContext
> {
> private:
> pqxx::connection m_conn;
>
> public:
> ServerContext();
(Continue reading)
RSS Feed1 | |
|---|---|
11 | |
23 | |
34 | |
18 | |
29 | |
34 | |
17 | |
37 | |
36 | |
3 | |
38 | |
2 | |
74 | |
76 | |
23 | |
53 | |
35 | |
47 | |
50 | |
49 | |
28 | |
31 | |
19 | |
17 | |
5 |
