Hey Mobi, 2010/3/15 mobi phil <[email protected]>: >> It depends, we are certainly thinking of a nice solution to support >> SQL dialects, especially w.r.t. different types. >> Do you have other uses in mind ? > > Just as usually, was writing my question under time pressure... I am > afraid you misunderstood my question.. > > What I mean one should define some keys/paths in the configuration > file, where to store uniformly DBO backend specific settings... :), I > try to finish my myqsl driver, but there are tons of settings that > need to be configured depending on the deployment context. I think > would be clever to define some policies, otherwise one day our > components would not love each other :)
Really, a mysql driver? Are you basing it on libdrizzle? How is it working out? I agree we should standardize connection parameters across the various backends. But that should happen on top of the 'native' connection string APIs supported by each backend. >>> 2. Doing DB operations on constructors (SqlStatement, SqlConnection) >>> is maybe not the best idea, as it makes exception handling, >>> deallocation etc. generally difficult. What happens if a driver throws >>> an exception on these constructors? >> >> I believe throwing exceptions from a constructor is perfectly fine ? >> (http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.2) > yes... but what you quoted tries to say the same... better to avoud... > but read here.. (pasted at the end of the email) > > my arguments are the same as here: (I had most of them before google > came into being :) ) > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Doing_Work_in_Constructors So their argument is based on "We do not use C++ exceptions." I am not going to open the exception debate, but, I tend to find them useful, especially to signal problems in situations like these where you interface with a database and pretty much everything can go wrong during every call. Also, please consider their reasoning: "On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions." I do not think we need to integrate with existing exception-free code, and if we do, it is usually a web application that will call API from another library, not vice-versa, so the propagation argument does not hold. And if you do use exceptions, then there is no reason not to use them from within a constructor (you cannot use them destructors, but they are encouraged for failing in a constructor as per the C++ FAQ). > Well... actually my problem is about knowing that after constructor it > is usable. But this could be marked with some extra state "unusable". > The constructor, or any other operation could set the connection and > statement to an "unusable state" (I am reffering to the existing > states defined in the sqlstatement) After a constructor, your object should either be usable, or not constructed at all (i.e. an exception was thrown). Please do not add an "unusable" state to a constructor. Regards, koen ------------------------------------------------------------------------------ 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
