From: Post-no-reply Tudbc Date: 2008-09-15T13:50:16+09:00 Subject: Re: A new database access framework for any Ruby (Iron or J) I am trying to give some more details to address a few questions that people asked. David Masover wrote: > On Sunday 14 September 2008 15:37:55 Robert Klemme wrote: >> Is it just me or do others also get the feeling that this is spam, >> trying to get some google ad clicks? > > I hadn't read thoroughly, but this is the part that reminds me of *ahem* > Bingo: > > On Sunday 14 September 2008 01:30:49 Post-no-reply Tudbc wrote: >> Even though TUDBC works for multiple platforms, the performance is not >> sacrificed because it is using a new paradigm and caching technique. >> Performance comparisons show that it is close-to-the-best and the best >> in various settings. > > "New paradigm" -- bingo! We have a winner! Well, history always shows that people tend to not believe in any new paradigm when they first surfaced. Didn't we say the earth was not supposed to be round? Well, the source codes for TUDBC are available for download, you can see them and try them yourself, then make your judgment. > "New caching technique", but no details -- hmm. I am currently writing an academic research paper about the overall architecture, and definitely I will share that when I am done. I am not selling the product, so I am just as happy to share my research with the world, so I annouced it in several forums (hopefully this is not a crime ;D). I do my diligence by announcing it in only the languages that TUDBC currently supports: PHP(s) and Ruby(s). I couldn't find any list for Java, C#, VB.NET, etc. The source codes are available for download for anyone interested to examine its correctness, so I didn't make any excessive claims that I cannot substantiate. > I'm willing to be proven wrong, but the site itself doesn't help: > > "Best practices: TUDBC promotes the best practices for coding styles > using The wording may be a bit ambitious, but I think TUDBC does it quite well. > super-strongly-typed SQL statement cache and connection cache." > > What makes a SQL statement "super" strongly-typed? Excellent question! This is part of the so-called new paradigm. When you get an instance of SqlCommand (an example in .NET for SQLServer), it is always generic, which could be a INSERT or SELECT or any other SQL statement in it. Not any more in TUDBC, you always get exactly the specific SQL statement you want to work with. (How? I am afraid you need to look at the source codes, because each language implements it differently, but TUDBC hides all the differences by creating a consitent interface for the getSQL() method which is explained later) Why is generic statement bad? You cannot enforce what it should or should not do. Let's say it is an INSERT statement, ADO.NET does not prevent you from writing codes to try to get a DataReader (like a result set) out of it, although we shouldn't and only at run-time it will cause error. The specific statement that you get from TUDBC will not allow you to do that (in the "standard style" which is from my original design; later two National Science Foundation (which is the most prestiguous research administration instituition in the US if are not familiar with) Program Directors gave a comment that it may be too restrictive for practical usage, so I relaxed this requirement to create an alternative more agile "EZ style", but it looses the super strongly-typed characteristic, but I could still mimic the strongly-typed characteric in another way.) Why is it called "super strongly-typed"? We already defined what is "strongly-typed". In fact, SqlCommand is "strongly-typed" already, but it is still generic in what it repesents inside. So I coined a new term that means it is stronger than the traditional sense of "strongly-typed". > And you do realize this is the _ruby_ mailing list, right? A lot of duck > typers here. Not really the best place for strong typing. I guess I should should explain more about what I mean. Actually, Ruby is still a strongly-typed language that doesn't require you to declare the type in advance. But by and large, Ruby is still a strongly-typed language, because "123"+3 would cause syntax error. It provides a more convenient way of "ducking" types. For example the very succint syntax of ".to_i" or ".to_s" is clever, because we convert types so frequently that "Convert.ToInteger" or "Convert.ToString" (in C#) or Integer.ParseInt or .toString() (in Java) would be too laborious. I admit that the super strongly-typed characteristic only applies to strongly-typed languages in theory. But I beg to diff, because it can also be enforced or helped by good IDEs to ease development. That's why I intentionally leave the wording as is. (Read more about exactly what I mean in the next two paragraphs.) My hope is that hopefully one day when TUDBC is widely accepted and IDEs eventually catch up, then actually there is a simple way to implement this feature inside any good IDEs, even for dynamically strongly-typed languages (like Ruby) and non-strongly-typed language (PHP, Perl, etc.). How? The IDEs just need to know which method requires support for super strongly-typed. For TUDBC, there is only one method, which is getSQL() method. So theoretically speaking, IDEs can find out the type of getSQL() requires, and it can then support this super strongly-typed feature, even for non-strongly-typed languages. As for strongly-typed languages (e.g. Java, C#, VB.NET, J#, etc.), existing IDEs (such as NetBeans, Visual Studios) already can handle the super strongly-typed feature. For example, whenever you use getSQL() and follow by a dot, the IDEs will auto-complete with exactly the methods that it shoud have and no more generic SQL methods. Nothing needs to be changed in the existing IDEs for any strong-typed languages to support this, and it works beautifully!!!! That's why it is called super strongly-typed, and that's why it is called a new paradigm, because it has never been done this way (I think, or at least in any of the existing database APIs). > But the real kicker is, login required for "source codes and tools", and > it's > got a custom license -- sorry, there are too many open DBCs for me to > waste > time getting a fscking _login_ for yours, especially when I'd rather be > moving beyond SQL anyway (see: CouchDB, ThruDB...) That is your choice, and I respect that. Hopefully I do dispel some of your misconceptions about TUDBC. p/s: As for another criticism of being a spam website to draw advertisements. Let's just say that it is so insignificant that right now my account still shows a balance of zero. Luckily I don't depend on it for a living. :D Cheers! -- Posted via http://www.ruby-forum.com/.