Forum OpenACS Development: Response to Query Extractor and Query Dispatcher

Collapse
Posted by Kapil Thangavelu on
I haven't done any work on the query extractor in several months
after being told that the openacs team had what it needed, but as
the original author of the extractor i think i can answer these
questions. In addition, i'm planning on doing some additional work
on the extractor in the near future so if you have any feature
requests/bug reports (with logs) please email them to me or submit
them directly to http://sindev.dyndns.org/Projects/OpenACS/tracker
(i'll be moving this weekend so the site will be down for a day).

first, if you're using the query extractor please take a look at the
README and use the log files as their there to help identify
situations which require manual intervention.

Gilbert the case you point out where the extractor is identifying
the wrong proc query association, is clearly an extractor bug. if
you could send me the log files from which generated this i'll work
on it.

The case with dynamic queries was a design decision that was made
before information regarding how the QD was to handle partial and
fully dynamic queries was known. In the case of a fully dynamic
query the QE will write a message to the logfile and ignore the
query. In the case of partially dynamic queries the QE will write
out the query as a fullquery with a message in the logs. I'll change
the behavior of the partially dynamic query into the now standard
partial query syntax. I'm not sure what the proper standard syntax
is for fully dynamic queries in xql files... ?

Some of the modifications by the openacs team, involved disabling
some of the logging, so I'm not 100% sure that all the relevant info
is logged.

the QE works with both proc and ad_proc as noted in the README. i
believe Dan did some work to make it also work with the template
dbapi.

As Dan noted the QE is not 100% reliable, it is meant as tool to
automate alot of the drudgery of porting. use it, save time, and
have fun porting, but do check over its output and the logfiles.

Incidentally if anyone is interested in porting to another rdbms,
please contact me, as i've done some preliminary work on tools to
automate the ddl (including function prototypes) porting to other
databases.