Changes to ticket 66de526498
By anonymous on 2009-11-28 21:35:42. See also: artifact content, and ticket history
- Appended to comment:
anonymous claiming to be btheado added on 2009-11-28 21:35:42:
I also noticed how these sql functions are missing from the current fossil implementation and I took a stab at porting some of it over from cvstrac.Both user() and cgi() both were straightforward.
The code for aux() and option() is more complicated. Maybe it will also be straightforward, but I haven't looked close enough yet.
I looked at the wiki() implementation in cvstrac and the functionality doesn't really seem like a good fit for a sql function. The function only prefixes the cell values with a special string that later triggers wiki conversion (and bypasses html escaping as for other normal columns). With this behavior, I don't think 'wiki()' can be combined with other sqlite operations very well. If the user wants to perform additional modification to the output of 'wiki()' with another sql function, then they would likely be surprised to find at the sql level that the output of that function is not the wiki converted text. I don't see a use case for doing that, but it makes it seem to me like it is a bad fit for a sql function.
So I took the approach of adding a new special column name prefix. If the column name is prefixed with the string '_wiki_' then the cells in that column will be wiki converted and the '_wiki_' prefix will be removed from the column name. All other column names prefixed with '_' will trigger the "new row" functionality as before.
What do you think of this approach?
I have these changes checked into a local clone of the fossil repository. I created my own branch for these changes, but then accidentally checked the changes into the trunk (I'm not well versed with the VC side of fossil yet). I'm not sure yet how to fix that. I guess I can just start over with a fresh fossil clone and make the checkins again.
Are you interested in having these changes pushed into the fossil repository?