I started to answer before the rest of emails came in.. > That would be indeed a solution. I am not sure that this would be the best solution. The driver should have callback for constructing any kind of statement. What happens if PostgresSql or others have in some syntax quote as delimiter, and others not?
> > Btw. The first release of Wt::Dbo did not put delimiters, but, it > turns out that it is quite easy to come up with a table or column name > that is in fact an SQL keyword. That is the reason to put delimiters > everywhere... I also figured if SQLite supports it, so will the bigger > database engines ? Well... that is a general pattern... One should avoid that, as one should avoid using C++ keywords for variable or typenames.. > Does MySQL not support it anywhere or only not in particular statements ? It seems that most of the commands have syntax without quote. Another serious design issue is that you make db equivalent of any std::string or WString the "TEXT". "TEXT" can have up to gigantesc sizes, like in mysq, and you cannot predict the size of the field untill you retrieve an element. As I see this is not the case for sqlite, but it is souriously the case for Mysql. This means that you always have to allocate megs of memory for a field that containes a date or an ID. So it is really necessary to be able to provide someway a flag about the length of strings. Maybe the best place would be the persist method of the DBO Types. The flag should be an enum like "SHORT, MEDIUM, LONG". I think most databases have this variation. SHORT would be up to 255byte, MEDIUM up to 255*255, and LONG would be sthg even more. Also a virtual method should be defined where each driver would retrieve the equivalent of these SHORT, MEDIUM, LONG etc. I also was reading bit about libdrizzle, but the lib seems to be more promising than doing sthg. The clearly stated, that MySql's prepared statemnt arch would not be supported etc., etc. Someway I agree with that. I also do not understand why Wt::Dbo went for the prepared statement arch, instead of doing simple queries. Prepared statements would be optimal > 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
