Re: A new database access framework for any Ruby (Iron or J)

On Sunday 14 September 2008 23:50:16 Post-no-reply Tudbc wrote:

> David Masover wrote:

> > "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?

Extraordinary claims require extraordinary proof.
There is extraordinary proof that the world is round, and not flat.

But I'm talking more about the arrogance of assuming that *YOU* have developed 
an earth-shaking, paradigm-shifting concept. A lot of people say that. Not a 
lot of people can actually back it up.

> Well, the source codes for TUDBC are available for  
> download, you can see them and try them yourself, then make your 
> judgment.

With a free registration barrier and a license barrier in the way. Which means 
it's going to be a hassle to even get the code, and possibly a hassle to 
discuss it later, if I want to cite snippets as an example of how bad (or 
good!) it might be.

I'm curious: Why did you choose to release it this way?

> > "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.

Even academic research papers have abstracts. Is your caching technique so 
complex that it can't be explained in 100 words or less? If not, it might be 
good to include that explanation when you talk vaguely about a new caching 
technique.

If, as you say, you're not selling the product, I can only assume that your 
goal is wide adoption. This would lead to quicker adoption of these caching 
techniques, if not the whole program -- and possibly, quicker adoption of the 
program.

But if it really is that complex, it's also that much harder to prove correct.

> > 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.

Are more complex queries supported, then? Like nested selects?

For example:

delete from users where (select count(*) from groups where groups.user_id = 
users.id) = 0

> 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.

Then, what about:

insert ...; select ...

Interesting, thanks for that explanation.

I'm still not entirely sure I see the use, though -- mostly because I can't 
imagine a case where I would be using an insert when I meant to select. If it 
somehow did manage to happen, it would almost certainly be caught by a unit 
test.

> 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".

What you've done is, you've made the return value of a SQL statement more 
strongly typed. That's something else you could put as a simple, <100 word 
explanation of what "super strongly typed" means.

> > 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.

True.

What that adds up to is, type checking is largely at runtime, not at compile 
time (or IDE-time). Which means that "strongly-typed" SQL already more than 
handles the typical Ruby need for types.

> 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 another place you're at odds with the majority of the Ruby community. 
The closest thing most Rubyists seem to use is TextMate, which is a really, 
really nice text editor, but not quite an IDE.

> 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).

And I would call it a new feature. Not a bad feature, but if that's your new 
paradigm, you've overhyped it by quite a lot.

> 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

Spam doesn't require money. I also file chain letters as "spam" -- you know 
the kind; "If you forward this message to ten people in the next ten minutes, 
you'll win the lottery! But if you don't, you'll lose your life savings!" No 
one profits from these, but I still consider them spam.

> Hopefully I do dispel some of your misconceptions about TUDBC.

Thanks for taking the time.

Something to remember: As savagely as I might attack your work, or your ideas, 
it's not saying anything about you. I don't know you, so I can't hate you. 
So, don't take it personally.