On Wed, August 9, 2006 17:49, Aleksey Kontsevich wrote:
> and I want my own constructor, something like this:
>
> TMyApplication(char ini_file) {
> // getting Conn string and trigger name
> ...
> // making some memory allocations
> ...
> // activate the trigger
> setName(N);
> setConn(C);
> };
> ~TMyApplication()
> {
> // clear memory
> ...
> }
But I think most of this is still possible with the existing interface,
except you're supposed to set up your connection before you create the
trigger anyway:
TMyApplication(pqxx::connection_base &C,
const std::string &N,
char *ini_file) :
pqxx::trigger(C, N)
{
...
// making some memory allocations
...
}
Now, you would still have to obtain your connection from outside the
trigger initialization. It strikes me as a fairly bad idea to create the
connection inside the trigger; you'd almost certainly want to do that from
outside the trigger. Trying to put the bulk of your application inside a
trigger doesn't seem to be quite right either... In Java I could imagine
that happening, but in C++ it just seems the wrong place.
If you want to have a connection only for use in this one trigger,
completely separate from everything else you're doing, and have both their
lifetimes managed together, then I think it would be cleaner to create a
class that _contains_ both the connection and the trigger:
class MyApplication;
class mytrigger : public pqxx::trigger
{
MyApplication &my_app;
public:
mytrigger(pqxx::connection_base &C, std::string &N, MyApplication &A) :
pqxx::trigger(C,N),
my_app(A)
{
}
};
class MyApplication
{
pqxx::connection_base conn;
mytrigger trig;
static string connection_string(std::string &ini_file);
public:
MyApplication(const std::string &ini_file, const std::string &name) :
conn(connection_string(ini_file)),
trig(conn, name, *this)
{
// making some memory allocations
...
trig.await_notification();
}
~MyApplication()
{
// clear memory
...
}
};
This is not perfect either (there are various ways of making it nicer,
depending on your taste) but it separates the concerns of receiving the
trigger and running code. In practice, for instance, I think you'll want
to use that connection for more things when the trigger arrives. I think
the code will come out more natural when you add that as well.
> I don't see any problem here: old code will continue to work as it is and
> new
> one will get some new opportunities. I looked through you code: there is
> no
> problem if m_Name is not set or differs - get_notifs() method just will
> not
> call the trigger::operator()(int) - trigger is switched off. The same
> thing
> on m_Conn.
Old code is not the worry here. The worry is new code that may contain
bugs that simply aren't possible with the current API!
Jeroen
_______________________________________________
Libpqxx-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
