Hi Andrew, > Hope I did not come off as arguing, it sure wasn't my intent.
I understand argueing as "exchange arguments", which isn't a bad thing at all. >>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? Which still means you need to do it first .... > [views with parameters] > 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, what do you mean by "turn 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. I used the UI to create a view, entering a "?" criterion for a numeric column, and saving the view. No problems. SELECT * FROM INFORMATION_SCHEMA.SYSTEM_VIEWS shows that the view was created. >>(Now is this an insult or a honor? Hmmmmmmm ... :) > > Honor...but don't go getting a big head over the compliment..*chuckle* *g* > 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? Well, also in the iTeam (the team designing a new feature) only one person argued for the "queries as views" solution. And what's such a team good for if I wouldn't respect this? :) > 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. Funnily, I see it the other way round. I think especially keeping existing API compatible (something a user will never see in the UI) is the hard part with the substitution feature (e.g. what about the XTablesSupplier in a SingleSelectQueryComposer?). But let's see. > 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? Well, the existing problem, which would need to be solved first, is that views are not updatable in HSQL at the moment. I did not yet investigate whether this is on the HSQL or the OOo side. Without solving this, having updatable multi-table queries wouldn't be of use in the "queries of views" world, of course. Thanks & Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
