I found (using oracle) that the uglier native bulk operation to custom type 
that you describe was in fact much quicker (sorry, I've long since ripped out 
the old version from my code so cannot give figures, but it was an order of 
magnitude quicker). I am using the canonical form of bulk update described in 
the docs. As you would expect, the batch size made a difference - I played 
around with various values to find a sweet spot for my data requirements.

I had vague plans to separate out the DB retrieval and native->user data 
conversion into separate threads. Since the DB retrieval for each batch almost 
certainly takes longer than the conversion, the two should be able to run 
concurrently, effectively reducing the data conversion cost to zero. This would 
require dynamic rebinding of 'into' parameters between each batch retrieval - 
not sure how possible that is at the moment.

Great library BTW, big thanks to the authors!

Phil

-----Original Message-----
From: Sören Meyer-Eppler [mailto:[email protected]] 
Sent: 09 November 2009 16:25
To: General-purpose list for SOCI users.
Subject: Re: [SOCI-users] WG: Bulk operations on custom types

Hi,

> What do I need to add to my type_conversion specialization make such a bulk
> operation possible?

This has been asked on this list a couple of times already. The
short answer is: it isn't possible. Bulk operations can only bind to
vectors of native types.


Related question: Is there any way to tell what backends support and
will benefit from bulk operations? The relevant backends in my case
would be PostgreSQL, SQLite, MSSQLServer, mySQL and generic ODBC. I
am under the impression currently only Oracle will actually use bulk
operations. Is that true?

Also, has anyone tested the performance of simulated bulk
operations? I.e. instead of using a custom type with say 5 fields
use 5 vectors of native types and select into them. Construct the
client side object later by iterating over the five vectors,
essentially copying the data one more time. Ugly, requires lots of
redundant extra code and my gut says it'll probably not be faster by
much (or at all). Correct?

cheers,

    Sören


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users

Disclaimer 
-------------------------------------------------------------------------------------------
This email message has been scanned for viruses by Mimecast.
Mimecast delivers a complete managed email solution from a single web based 
platform.
For more information please visit www.mimecast.com
-------------------------------------------------------------------------------------------
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users

Reply via email to