Re: db:execute context

On 15 Nov 2006, at 16:06, Tomasz Rakowski wrote:

Thanks for suggestions,

 I completely understand your design decision, but from the other hand 
 it is also usefull to have in db:execute tag an access to parameters and variables which are in function context like you have done eg. in for-each tag where you also create new variable but still has access to others variables.

Sometimes function variables I would like to use inside db:execute are quite complex documents , which I wouldn't like/can't pass through SQL query.

Anyway I found it quite annoying that I have to do such strange things to pass parameters to db:execute tag. And we have to do this quite frequently.

At the moment you use two different notation to access db variables {$xx} and function variables <o:_eval select="$xxx">, but internally you store both variables in the same place RuntimeContext.variables (as a result you can access db variables also using <o:_eval select="$xxx"> notation).  Maybe in db:execute you could create seperate container/variable just for db variables and {$xx} tag would access variables only in such container. You could add this container to RuntimeContext.variables as a single variable along other function variables  and remove it when db:execute finishes  (exactly as for o-foreach).

I guess that in such case it would be not possible anymore to access db variables using <o:_eval select="$XXX">, but as I understand suggested notation is {$xxx} anyway.  

The {$xxx} notation is equivalent to <o:eval select="string($xxx)"/>, ie it produces the string value of the expression within brackets (in this case a variable reference). It is used in attribute value substitution (ie <value id="{$id}"/>) and is only a convenience mechanism - in database result templates it can be used in text sections as well as attribute values to make it quick and easy to write templates.

There are not really different types of variables, eg local and global, in o:XML. This is to keep the language conceptually simple. All variables are referenced and handled in pretty much the same way, be they function parameters, local variables or type variables. As you know, the database results are set as local variables within the result template only, and to avoid conflict no other variables are in scope at this point.

The question about variable scoping within database result templates is, as far as I'm concerned, up for debate. I think a possible solution to avoid 'over-scoping', ie conflicts, is to have type variables in scope within result templates, but local variables out-of-scope. I think this would allow easy access to data, while encouraging OO encapsulation. What do you think?

The side-effect of this is that if you do 'select * from foo' and table foo has a column foobar, then a type variable named foobar would be automatically modified. As long as this is understood, this can be used to great advantage as a way of setting/updating type variables from the database.

As I think about it longer maybe it would be even better solution if we access db variables like <o:_eval select="$db/xxxxx"> where $db would be the name of variable defined in db:execute tag (like in o:foreach tag). 
In such case we could access db variables even in nested queries even if they return columns with the same name.

something like:
<db:execute name="result1" sql="select foo from bar">
  <db:execute name="result2" sql="select bar from baz">
     <value name="{$result1/foo}">{$result2/bar}</value>
  </db:execute>
</db:execute>

This is not bad at all, though I'm not sure the nesting capability is massively useful. Maybe I'm wrong. Instead of changing db:execute, this could maybe be done as a different extension. db:retrieve, db:fetch?

I would also like to expose the database mechanics such as connection, query, result set etc as accessible, useable o:XML types with a solid API, though that would involve quite a lot more work...

Thank you very much Tomasz for your suggestions, do keep them coming! I'll let you know when I'm next working on the database functionality, probably in the next month or so.

/m