Hey Mobi, 2010/3/22 mobi phil <[email protected]>: > 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?
Then that would be rather big bug in that database. This kind of lexical syntax rule is really basic. And per the other mail, it seems that Mysql also supports it ? Or was your observation 'Well it should work...' ironic ? Btw. we have now also a postgres backend (in public git), contributed by Hilary Cheng, which deals with all this just fine too. I am currently implemeting proper support for date and time, and modified the backend API so that SQL data types can be different depending on the backend. >> 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.. But, by putting quotes around every identifier, there is no limitation, so I don't think you can draw the parallel to C++, since C++ does not provide any support (nor should it). > It seems that most of the commands have syntax without quote. The syntax of each command will reference the syntax for an identifier, which states it can be quoted ? It seems that the default quote for MySql is the back-tick rather than the ANSI-standard double 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 I believe that is indeed not optimal (but an easy start, and as good as it gets for Sqlite). We should extend support for the std::string and WString by adding an optional 'size' parameter to the dbo::field() function call. The same 'size' argument can also be used to indicate the size of a (binary) blob of (C type const char *), which we will also want to support. These two things are on my wish list for Wt::Dbo. > 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. Why not support a proper size, so that the back-end can decide to store the string as a varchar(x) for example ? > 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 That would be too bad indeed. https://lists.launchpad.net/drizzle-discuss/msg05187.html however suggests that they are going to support it ? 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
