Consistency is good, of course.
I agree that we should absolutely remove current inline queries where they're also in an .XQL file, given that the .XQL files always take precedence.
But if we do remove inline SQL where also in the .XQL file, I don't think consistency is a major concern under this scheme, since the process for finding the SQL code will not be interrupted.
With the proposed scheme, after removing extra inline queries, but before moving all common queries from .xql file into .tcl file:
1. Open the Tcl file of the page or library proc to find the db_* command. (100%)
2. If there's inline SQL, you've got the query (~20%)
3. If not, go look in the generic .XQL file (~50%)
4. If not, find it in the db-specific .XQL file (~30%)
With the proposed scheme, after removing extra inline queries, and after moving all common queries from .xql file into .tcl file:
1. Open the Tcl file of the page or library proc to find the db_* command. (100%)
2. If there's inline SQL, you've got the query (70%)
3. If not, find it in the db-specific .XQL file (30%)
If this proposal is rejected (after removing extra inline queries):
1. Open the Tcl file of the page or library proc to find the db_* command. The SQL part will be empty. (100%)
2. Open the generic .XQL file, to see if the query is there (70%)
3. If not there, go check the db-specific .XQL file (30%)
My point is that the proposal doesn't interfere with the development flow, but instead it lets you save the hassle of opening and searching through another file 20-70% of the time.
Oh, well, Don's and my position are clear. Can we get some OCT votes, so we can get this matter resolved and move on, please.
/Lars
