Le jeudi 17 janvier 2008 à 17:01 +1000, Gary Bentley a écrit : > Hi Nathan, > > Just on the annotation, if I set it as request will that mean that there > is 1 JoSQL object per request?
Yes. > For example if a template is processed in a single request that has 2 > josql.execute calls (say) will it be the same JoSQL object that is used > for both? Yes, but the two josql.execute calls will be called sequentially by the same thread. > I just need to know since it is the query that isn't thread safe but if > the same object is used for both then I need to create 2 query objects. You should not need two different objects in this particular case. Claude > Thanks, > > Gary > > > Gary Bentley wrote: > > Thanks for that Nathan, I'll probably use the LoopTool as a template, > > it appears to have the items you are talking about. > > > > Gary > > > > > > Nathan Bubna wrote: > >> 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] > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
