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

Error in include template "/var/www/openacs/packages/openacs-bootstrap3-theme/resources/templates/packages/forums/lib/search/search-form": can't read "form:id": no such variable
Collapse
33: Re: TIP #37 (Proposed): Queries in XQL file conventions (response to 1)
Posted by Dave Bauer on 12/10/03 03:44 AM
Benjamin,

I understand your frustration. Moving all the queries is a huge job and touches almost every file in the system. It would be a good idea to write automated tests to make sure that after such a change, everything still worked the same.

I won't guess how many volunteers working for how long it would require, but I can imagine that there are better things to do with their time. I didn't mention any top 3 priorities, but there are still things that are actually broken that noone has stepped forward to address.

Collapse
34: Re: TIP #37 (Proposed): Queries in XQL file conventions (response to 33)
Posted by Benjamin Bytheway on 12/10/03 03:56 AM
Granted, it would be a big job.  But I don't think that means the proposal should be vetoed.  The OCT should judge proposals on their technical merits. If it is something that would ultimately be a good idea, get the proposal hashed out, and stick it on the roadmap somewhere.

Sweeping these kinds of things under the rug isn't the way to go, imo.  With Tcl TIPs, the one proposing the change is responsible for either implementing it, or finding someone who will implement it.  A TIP approval says nothing about when it needs to be done, or even that the OCT must take time to do it themselves. I see it as moving that proposal onto the official "todo" list.  Scheduling those todos comes later.

Collapse
35: Re: TIP #37 (Proposed): Queries in XQL file conventions (response to 34)
Posted by Malte Sussdorff on 12/10/03 09:22 AM
Okay, maybe the reason for veto given by Caroline does not stand a technical ground, but the reasons given by others in the OCT definitly do.

Furthermore, you don't loose functionality at the moment. All the veto says is: We do not encourage to put SQL code in the TCL code for consistency. And if you expect your code to make it into the toolkit you are highly encouraged to get you SQL code out of the TCL code and put it in XQL files. The teaching and training materials will train to use XQL files.

For development you can always us inline SQL (it's not like we'd turn the functionality of using inline SQL off).

Collapse
36: Re: TIP #37 (Proposed): Queries in XQL file conventions (response to 35)
Posted by Joel Aufrecht on 12/10/03 10:53 AM
1) If someone is on the OCT, their vote counts regardless of whether or not you agree with their reasons.  If you really think they're wrong, you need to get six OCT members to agree.

2) I think the original TIP was slightly unclear in that it did not describe the current situation fully.  The current situation is, I believe, that "best practice" is for all SQL to be in XQL files.  The veto means that this is still the case.

3) The status quo leaves two obvious questions which I don't believe were directly addressed:
  a) Will we reject packages that don't meet this best practice?  (No idea what the consensus would be - sounds like a good show-of-hands question in an OCT meeting)

  b) Will we change the kernel to enforce this best practice - ie, will we start ignoring any SQL in TCL files?  Argument for: enforces consistency.  Argument against: is a useful shortcut during development; requires lots of work with only a potential, future reward.  I think this one is a clear no, and status quo is "no," so unless someone starts a new TIP I don't think this issue is open.

Collapse
37: Re: TIP #37 (Proposed): Queries in XQL file conventions (response to 36)
Posted by Jeff Davis on 12/10/03 11:51 AM
For the record, the voting looks like: 
DaveB: no (?)
Don: no
Jeff: yes
Lars: yes
Roberto: ?
Peter: ?
Caroline: no
Tilmann: no
Malte: no
where ? means didn't vote and (?) means I think it was a no but I am not sure if it was no to the proposal or if it was just no to trying to fix any that currently exist (remember that the original proposal is simply one of coding standards i.e. explicitly stating that having generic queries in the .tcl file is acceptible).

Apologies if I got anyones vote wrong here.

In any case it seems like the required 2/3 is not there so this is rejected and the status quo coding standard: all queries in .xql files with the exception of things that cannot be multidb by design (schema browser for example).

It's also worth noting that the existing packages do not adhere to the existing standard very well in any case, and regardless of whether this is approved there is a lot of work to be done to bring things into line.