On 15 March 2013 14:57, Ricardo Fabiano de Andrade <[email protected]> wrote: > > Which is the preferred soci way to create out-of-order and other kinds of > complex statements?
Ricardo, I'm not sure I understand it clearly, without a (pseudo-)code sample. > Some examples of what I mean: > 1) Creation of SQL statements and binding of the respective variables based > on conditions or loops. This is a canonical way to perform repeated execution of the *same* statement. It isn't clear where the out-of-order execution applies here. > 2) Bind the variables first, then append the SQL statement which may be > decided later between an INSERT or a UPDATE. Do you mean you have known set of data objects you want to bind with into/use, but variable set of SQL statements? If that is what you mean and assuming use of public interfaces only, then you have to work with two different SOCI statements, create them and bind data for each and every. In the upcoming SOCI 3.2.0, there is new feature called query transformation https://github.com/SOCI/soci/pull/82 I sense it may be helpful in scenarios fr switching between type of query for the same set of data bound. > 3) Execute a SQL statement during the creation of another one to make > decisions regarding the contents of the later. This one sounds like common pattern used in Web pre-AJAX era, where server-side scripts executed series of SQL statements to control flow. > 4) Work on the WHERE clause first, then in the main clause > (SELECT/UPDATE/DELETE). This approach is actually easy to achieve with the query transformation mentioned above. > Using directly the soci::statement class you can do all of them at some > extend but you lost all the soci's syntactic sugar, you must manage the SQL > stream/string by yourself and you need to call a bunch of members functions > in the proper sequence to make the whole thing work. Look at motivation behind SOCI and the syntax-first approach explained by Maciej in this article http://www.drdobbs.com/database/a-simple-oracle-call-interface/184405930 Managing calls to session and statement functions manually is perfectly valid approach as, quoting Maciej's article, "low-level concepts of database operation are still exposed". The convenient syntax is another approach, preferred in many if not most cases. Both approaches are perfectly valid in SOCI. > Holding a soci::detail::prepared_statement_temp_type variable you keep all > the soci's syntactic sugar and you can do 1), 2) and 3) with some > limitations (you must append an empty string to soci::session to clear the > query stream). However, I don't think using soci's internal variables is a > future proof solution. > > A third solution (what I'm doing right now) is creating a wrapper around > soci::statement which works like soci::detail::prepared_statement_temp_type. You can do whatever works for you, but the obvious intention behind soci::detail is hide what's part the library interface. SOCI does not make any hard promises regarding API stability, so it may change between versions, if that is necessary. So, I can't tell what is future proof and what is not. > What are your thoughts and experiences with soci regarding such situations? Not much from myself other than that I have used approaches 1) and 3) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
