> First of all, there is no requirement for using prepared statements. > You could always wrap the Dbo backend around normal sql queries. I know that. However I have some (maybe weak) arguments against it:
1. the Dbo design seems to be more "prepared statement oriented", that is advantages of prepared statements (like repeating them often) were intended to use, and I completelly agree. In one session you might want to query for the same type with same key, but different values. In this case prepared statements are suposed to bo faster (how much, no glue) 2. My driver is already there. 3. In the context of current design what I was asking makes sense. > Secondly, if you opt for using prepared statements in the Mysql > backend for Wt::Dbo, then yes, after reading the documentation for > usaging prepared statements in MySQL's C api I start seeing your > problem. Without getting information from the application about the > maximum acceptable amount of memory to occupy you would have to guess > a good value without knowing if it fits the application's needs. You see... that means trouble served saignant. > So there are two possible routes to take: > 1) Do not use prepared statements for the mysql backend. This would > mean the implementation is not as straight forward as the pgsql or > sqlite backend, but it should be possible after all. Is there any > specific reason for choosing prepared statements in MySQL over normal > queries? No... I would better go for my api :) > 2) Wt starts providing an interface for the 'mysql special case' in > prepared statements. In this case I'd rather not see any changes in > the existing method signatures but implementation of a specific > "options" interface for dbo, where one can get a) a list of parameters > a certain backend accepts, b) a method to set specific parameters and > c) a method to get the value of such a specific parameter. Would not call it necessarily "special case"... I do not know how it is solved in postgres driver (will have a look if time available), but I am almost sure that oracle has the same model, and some common sense tells me that this is the tipical model for client-server. Furthermore what you are proposing would solve the case of the create statement, but not the memory allocation. Memory allocation is Dbo C++ type related, so best place would be the constructor of the SqlStatement, as there is no other "memory" of the driver about the types. -- rgrds, mobi phil being mobile, but including technology http://mobiphil.com ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
