[Libpqxx-general] transactor select results?

[Robert Backhaus-pqxx]

On Wed, Dec 30, 2009 at 1:15 AM, Remco Post <remco at pipsworld.nl> wrote:

> HI,
>
> On 29 dec 2009, at 15:20, Robert Backhaus-pqxx wrote:
>
> >
> > When you write your transactor, include private attributes to store the
> data that your queries will return. In your perform() function, store the
> information in those attributes. In on_commit(), you can move the data out
> of the transactor.
> > As the pqxx::result is part of the transactor, you should not reference
> it outside of the transactor.
> >
>
> I see no difference between your use of public member variables to expose
> your query results or having a member function return a reference to private
> variables. I'm more or less tempted to hide all variables, allowing me to
> change implementation without changing my interface. Admitted, directly
> exposing the caller to a pqxx::result might not be a good idea either. My
> idea was to build a generic transactor that would work for about 90% of all
> of my database queries, and only build specific transactors for more complex
> matters.
>

The problem is that the transactor framework creates a copy of your
transactor and executes that. So in this code:
mytractor T;
T.query="Select * from table";
C.perform(T);
T.R[1],[0];
R will _not_ contain data. The data is in a copy of T that was made just to
do the transaction. This is done so that, on any error, the copy can be
dropped, a new copy made, and the transaction retried, without causing any
problems.

Note that in my code, the output item was a pointer to the integer, not the
integer itself.

Using an external pqxx::result inside your () would break the encapsulation
of the transactor. You would have to have an internal result and an external
pqxx, and copy the internal one to the external one.

My advice: get used to using the transactor, and make a new one for each
action. The only difficult part is working out how to use them: Once you
have done that, there isn't that much boilerplate you have to add. The
robustness they create is worth it.


> > I guess that the answer is: outside of your transactor, you should be
> done with anything databasey. When the transactor is finshed, you should be
> left with the objects of your program, manipulated as requred by the
> information extracted from the database.
> >
>
> That is one way of handling things, and I might actually go that way.
>
> > Here is one of my uses of the transactor framework.
>
> Thanks, it does give me some insight into how you handle things.
>
> --
>
> Met vriendelijke groeten,
>
> Remco Post
> remco at pipsworld.nl
>
> _______________________________________________
> Libpqxx-general mailing list
> Libpqxx-general at pgfoundry.org
> http://pgfoundry.org/mailman/listinfo/libpqxx-general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pgfoundry.org/pipermail/libpqxx-general/attachments/20091230/725172df/attachment.html>