On Jan 16, 2008 2:27 PM, Christopher Schultz
<[EMAIL PROTECTED]> 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.
Definitely use request scope if there's any thread safety concerns.
With VelocityTools 2.0 (still in beta, but final release is largely
waiting on feedback and finishing docs), you can even add a
ValidScope(Scope.REQUEST) annotation to your tool class, to prevent
users from using the tool in any other scope. Also, if your tool will
be needing access to the current context (in VelocityTools 2, just add
a setVelocityContext(Context ctx) method and it will automatically be
given to the tool each request), then be sure to use request scope.
(Apologies for all my not-so-subtle plugs for VelocityTools 2; i want
to be sure people are motivated to upgrade from 1.4 soon :)
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]
