Evening Frank,
preface: Finally convinced by discussions both here and in our team, I'm
currently rewriting the spec based on the substitution approach. So,
every argueing here becomes a little bit academic, but perhaps
nonetheless interesting :)
Hope I did not come off as arguing, it sure wasn't my intent.
But the Developer Article Contest is about articles, not about actual
development, right?
I suppose trying to do it, and assuming it works, then wrtiing an
article about how one did it might qualify. Who knows?
Might be a project for the Google Summer of Code:
http://wiki.services.openoffice.org/wiki/SummerOfCode2006#HSQLDB:_editable_views
(probably too late, applications are running this week only)
The projects you have listed as possibles all sound good already, and it
appears there is already interest in the one for a single file version
of HSQL.
Actually, I did not test this to an end. What HSQL allows is to create a
view containing a parameter. In OOo's UI, since we do not know about the
parameters (after creation) anymore, we don't fill them, thus the
resulting "table" is empty.
What I assume (but did not test, yet) is that filling in those
parameters programmatically, before executing the statement, should give
the proper results. If so, then supporting parameters in views is just
knowing that there are parameters - everything else is already there in
Base' UI.
I did a little more testing on this also. The problem I am running into
is that if I use the designer to create a query with a parameter then
try to convert it to a view it fails, HSQL;s create view statement does
not seem to like the syntax put out by the designer. If I 'clean it up'
by hand then issue the command in the SQL window it will take it, kind
of. What I end up having to do is turn the parameter into a string,
which is fine for varchar and even date fields. For all numeric columns
however the create statement fails again, this time with a 'wrong data
type' error. But again, this was all black box testing, and quite
simplistic.
(Now is this an insult or a honor? Hmmmmmmm ... :)
Honor...but don't go getting a big head over the compliment..*chuckle*
Yes. Still, IMO (and I think we just differ in this opinion), for the
embedded HSQLDB database (my implicit requirements to satisfy this DB
only), "views as queries" would have provided a more seamless user
experience than "subtituting sub queries".
Anyway, I'm trying to pretend I'm not an ignorant, selfish,
argument-resistent egocentric, so I suppose we'll go with "substituting
sub queries" :)
Wel then I would say this based on my personal experience: if you feel
that the query as view approach is a better way,then defending your idea
in a vigorous manner makes you none of those. Besides, who wants some
one on an engineering team that doesn't have faith in their own
abilities to solve problems, so long as they understand that every
decision is a trade off in some regard?
My bottom line is this - I think going the route of using views is going
to pose a much higher risk, meaning it will end up taking more
development resources then the substitution route, and will not offer
significantly greater functionality. Also, I have to think you have the
need to enhance the client side query feature such that multi-table
queries are updatable on your radar screen. From reading the HSQL mail
lists it appears they may be offering some help with this in the next
major release, would not moving to use views now, complicate your
ability to take advantage of that enhacement, when it is available?
Drew
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
