Forum OpenACS Improvement Proposals (TIPs): Re: TIP #37 (Proposed): Queries in XQL file conventions

The current query extractor works at least to the 90% level, tclparse would be a better base, sure, assuming we actually need a really good tool of this sort, which we don't, since it was really just an aid to porting.  The current extractor also converts a fair number of simple Oraclisms to PostgresQL, and flags most other problem areas that can't be machine-converted easily.

As far as inventing tools to make both camps happy ... it strikes me once again that as a community we have a very difficult time concentrating on the important things.

And this ain't one of them, frankly.  We shouldn't be thinking about writing a tool in order to avoid making a decision.

If we write any tool at all, it should probably be one to organize the contents of query files inline, using -generic, -postgresql, and -oracle switches.  Get rid of query files and the query name parameter and be done with it, if people don't like them.  This would maintain the consistency I feel is so important, at least, Lord knows I have no emotional investment in queryfiles per se, I'm just devoted to doing things one way and one way only unless there's extremely good justification for not doing so.

But maybe I'm flogging a dead horse.  The rest of the toolkit's a mishmash of conflicting coding styles, after all.

John's optional pre-processor idea is kind of interesting, but IMO probably not such a hot idea over all. Even if it worked 100% reliably, it would probably require significant extra maintenance, for in the end, no real gain. If the OpenACS project was much larger than it is and this sort of pre-processor was the only thing that would prevent a FreeBSD vs. NetBSD type of fork, then it would definitely be worth using. Otherwise, sounds like a nify solution in search of a real problem.

On the other hand, if that optional pre-processor is attractive and important purely because of performance problems (in even some cases) with handling the XQL files, then something else about the OpenACS XQL architecture or tools is probably wrong, and should be addressed separately.

Longer run, seems that Don has tentatively (hypothetically?) suggested eliminating the XQL querfiles altogether, and defining a simple syntax for putting all the db-specific SQL into the same Tcl files. Not merely a -sql switch for inline queries, but several at once, "-generic, -postgresql, and -oracle"

The main advantage I see there is it lets (indeed, forces) you to see the same query for all the databases together at once. Upside is this would push much greater cross-db knowledge, and help eliminate spurious drift and redundancy in the Oracle vs. Postgres queries. All "official" OpenACS packages are supposed to support both databases anyway, and this would make the work of doing so somewhat easier.

The downside of course, is that it does tie support for the different databases more closely together. In the past people seemed to think it advantageous that, at least in theory, some outside group could decide to add support for a 3rd database just by adding a whole bunch of new XQL files, without having to touch the rest of the toolkit at all. But given history of Oracle and PostgreSQL support, and the continual ongoing development of the OpenACS toolkit itself, I doubt that any such "just drop in support for a 3rd database" project would be that simple. My guess is it that in reality it would need extensive co-ordination and some changes from the core OpenACS developers no matter what, whether the SQL is all in separate XQL files or not. What do you think, is my guess here wrong?

But, really, Don's "-generic, -postgresql, -oracle" suggestion is a major change that would affect a lot of people, and nobody's going to do it anytime soon, right? (My guess is probably never, but not till OpenACS 5.1 at the very earliest.)

Six of one, half a dozen of the other...