I am trying to give some more details to address a few questions that
people asked.
David said:
I hadn't read thoroughly, but this is the part that reminds me of *ahem*
Bingo:
"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.
Cheers!
