Hi Andrew, 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 :)
>>(Except that when we do not implement "Queries in Queries" by "Queries >>in Views", then this means we probably won't invest the effort for the >>editable views :) >> > Actually this sounds like a darn good add on for some one to work on. > That developer article contest is going on again in May, isn't it? But the Developer Article Contest is about articles, not about actual development, right? 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) >>Yes, in fact currently HSQLDB enforces the integrity, so it is as you >>describe (well, except issue 64885 :( ). Ideally, it would be best to >>recognize the invalidity of a view at the very moment it is actually >>*used*, but so far I couldn't convince the HSQLDB project that this >>would be best from an OOo user's point of view ;) >> > I can not agree with you on this point Frank. Views area known commodity > in the RDBMS world. Insuring that they run, as expected, is a good thing. There might be different shades. Again, comparing what Joe Average gets when he renames a table column in MSA and a table column in Base, assuming that an existing query resp. view is based on them: In the one world, this is allowed, and executing the query yields an error. In the other world, renaming is prevented with an error message. I am not really sure what is the best solution for Joe (not for RDBMS-experienced power users), but tend to think tolerance is better here. >>Well, this shouldn't be a problem. HSQLDB allows storing parametrized >>views, but currently OOo doesn't respect this in that it doesn't know >> > You don't mean that HSQL has some native support for replaceable > parameters do you? 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 quick search of their forums and > documentation before my last message and couldn't find any mention of > it, granted I did not expect to find any. I take it then you mean that > one can store a string value as part of the select statement that > represents the parameter? Yes, you can do that now. Then OO could read > this select statement before the engine creates the temporary table, > prompt for the actual value and replace the string in the select > statement, then hand this back to the engine. Sounds to me a bit like a > $50.00 fix for a $5.00 problem, Sure, this would be overdone. I'd take an approach to simply know about the parameters, ask the user for their values, and fill them in. >>In general, I think the whole issue depends on the requirements. >> > Yes! [ Frank, you are a master of understatement at times, and that can > be a good thing for a project manager - of course product managers are > usually the ultimate masters of the art :-D ] (Now is this an insult or a honor? Hmmmmmmm ... :) >>(Though I still don't like the fact that the whole "Queries in Queries" >>feature depends on the parsebility then :-\) >> > A very real issue, not easily dismissed. It may be however that this is > a case of blending issues together. The question of the query designers > support for built in procedures and functions is an issue seperate from > that of nested queries. It has an affect on the usablility of nested > queries, for sure, but in and of itself does no seem to be a driving > factor one way or the other regarding implementation, IMO. One reason I > say this is, if nested query support is implemented by substitution then > support for views is still available. Therefore if a person needs to use > a query that can not be parsed by the designer they are still able to > use the current procedure of converting this query to a view first and > then using it. Further, once nested queries are available any > improvements to the designer's parser in support of procedures, > functions and extended SQL constructs should automatically expand the > usability of the nested query feature and diminish the need for this > 'create a view first' work around. 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" :) 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]
