...I have to think more about the API of this component but first I want to talk more about the background of my idea. I had several discussions with Alex Schatten and we came to the conclusion that, generally spoken, there are two database usage scenarios:
1. Enterprise Level
Where you need java code and/or O/R mapping tools, no question about this.
2. Simple database applications
Usually very small projects where you need only a few 'interactive' pages.
If you are familiar with O/R-mapping tools I always recommend them, also in scenario two...
Ok, but our users lists shows clearly that many people are doing stuff directly in SQL, for various reasons, including the welcome "transparency" of SQL when doing simple things.
And I'd add a third category
3. Read-only database publishing or mining applications
Where you do no transactions, only queries, and where O/R mapping does not bring much to the SQL -> XML -> whatever chain.
...IMO there are users who don't want to write programmes at all. They prefer XML declarations. So the question is 'How can we support them?'.
Don't you think many of these users would prefer writing simple scripts rather than XML declarations?
But I'm thinking more about providing an alternative to the ESQL / SQLTransformer stuff, maybe you're seeing things from a different point of view?
...WDOT? Maybe we should collect some proposals and then poll our users?
Hmmm...it might be better to come up with examples or use-cases of what you think a ModularDatabaseComponent could be so that people can judge on code. Otherwise I'm afraid a pool could lead to much talk without a concrete outcome.
Unfortunately I currently lack the time to work seriously on the Groovy/DB stuff. I'll try to not talk too much about it until something usable is here ;-)
-Bertrand
