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

Collapse
Posted by Don Baccus on
Jon - the reuse of queries was one of the arguments tipping (no pun intended) us in the direction of separate queryfiles rather than using conditionalized statements inline.  I think it is possible now but just hasn't been done.  Or perhaps the search algorithm was never tweaked to make it possible.

Lars - one (slight) benefit is that inline queries are slightly more efficient, though in practice there's no evidence that queryfiles are a barrier to adequate scalability (the RDBMS parse, optimization and execution time far outweighs query lookup time).

Collapse
Posted by Lars Pind on
Leaving aside for a moment the question of consitency with the past, let's talk about what the preferred coding standard should be.

Deciding to use namespaces, named parameters, ad_form, /www/resources and /lib directories, or any other new preferred way of doing things requires a break with the past, and, when resources allow, reworking existing code to match the new coding standard.

Then once we've found the new coding standard, we can determine how to get there. This would fall within a range of options, including:

- It's too much work, stick with and enforce what we've done in the past

- Feel free to change old style to new style when you come across it

- Stick with old style for current release, and in a future release we'll rework the existing code

- Rework all existing code now

Needless to say, I'll be happy to follow whatever decision we make through the TIP process.

Also needless to say, I personally find that moving all queries to .xql files is a waste of time.

Regarding reuse of queries, I find that wrapping them in procs allows for cleaner reuse than using some other proc or page's query. The query executed by a proc is part of its internal implementation, not part of the public API guaranteed to provide backwards compatibility, and thus shouldn't be done.

Alternatively, a package could provide a set of public named queries that would be part of the package's public API, which could then be used both by the package's own procs and pages, as well as other packages.

/Lars