From: gustin Date: 2008-09-16T00:44:37+09:00 Subject: Re: A new database access framework for any Ruby (Iron or J) does Tudbc support Visual FoxPro tables? I"ve been searching for a good way to write back to VFP with Ruby for awhile (the dbf gem does a great job reading from). thanks, gustin On Sep 15, 12:50 am, Post-no-reply Tudbc wrote: > 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 viahttp://www.ruby-forum.com/.