Hi Chris,
Thanks for the info.
For the bind variables is it possible to use "?" as the placeholder like
you can for JDBC. Is that what you meant?
Gary
Christopher Schultz wrote:
Gary,
Gary Bentley wrote:
For the class name, it's needed because during the parse it uses the
class name to resolve method/field accesses. Without it resolution
would be needed at execution time. In theory it's not needed but it
also allows the query to be parsed into the relevant tree of objects
so that it can be reused for execution.
Gotcha.
It also has the benefit of making the query more readable to humans,
so if you pass the query around others can tell what class it is
operating on.
When I was reading the "quick description" on the website, I was
confused at first because it wasn't clear that a collection of
existing objects were being passed-in as a context to evaluate the
query (until I kept reading, of course). At first, I thought that
"SELECT * FROM java.io.File" would magically read from the filesystem.
Silly me!
There is one issue, you said that the tool is put into the
application scope, however JoSQL isn't thread safe, is it possible to
get the tool to be created per thread? (I could however use a query
pool and normalize the query string if not)
That's really up to you. Velocity Tools itself will not create a new
tool per thread, but you can specify that a tool should be
request-scoped (that is, a new one is created for each request). Since
Velocity Tools was really created for webapp-use, and webapps should
only use a single thread for each request, this works out just fine.
If the JoSQL processors are not thread safe, you can simply direct
your users to specify "request" scope when configuring the tool in the
Velocity Tools toolbox.
I do have plans for a future enhancement to allow a bind variable to
be used of a class name instead so that it can be more dynamic.
Speaking of bind variables, I found myself a little thrown by their
syntax for the simple reason that it differs from JDBC. Perhaps you
could offer separate parsers at runtime for those who prefer the
JDBC-style syntax.
Good luck,
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
