Questions on Named Query

Question

We have a few questions about named query.
According to the Toplink documentation, we can register the named query in 2 places.
1. Register the name query in the “query manager” in a Session level - The documentation said that these are for “GLOBAL” queries.
2. Register the name query in the “query manager” in a Descriptor level. These “Descriptor level” query can be defined via the Toplink workbench or defind via Java code and load in the Descriptor via a post-project load amendment method. The documentation also mentioned that once the project is login, we cannot add named query to the descriptor.
We have a few questions.
All querys are related to a class, so what do we mean by “GLOBAL” queries ? What is this “GLOBAL” means.
Is there any restriction in adding query to a session. Can we add query to a session after the session is login ?
What we like to achieve is something like this.
Ask the session for a query “findElectionByEmployee”, if nothing returns, construct the query, add this named query to the session.
Can we ask a clientSession for a query using getQuery(string)?
Or we can only ask a serverSession for a query ?
How about adding query to a session, can a clientSession add a query back to the parent ServerSession, or we need to add the query directly to a serverSession ?
We have hundreds of queries, not all of them used all the time, so adding the query to the session “on demand, or Just in Time addition”, will be most memory saving rather than starting the system with hundreds of query.
Another issue we have about using descriptor based query, specially those that is define via the toplink workbench, is that it create sort of an administrative single point of entry. For a system that have a lot of query, to single file the creation of the query to a single person, or a few people, can be administratively difficult, even though we appreciate the “central and single point of control aspect of it.
So what is your observation in the use of named queries with your other clients ?
Is that a popular feature that your customer use ? Do they like to define the query in Workbench, can this solution “administratively scale” ?
Do you see “just in time” add of query to a session, if that is all possible.
Currently we have a simple query mechanism, each DAO method eg findElectionByEmployee, will contruct the query, with the expression builder, expressions etc and after one execution, throw that away and redo the same thing again in the next method invocation.
We want to avoid that but we do not want to centralized the definition to a central “Toplink Mapping” person. For a fairlt big system like ours, that have 20-30 DAO with hundreds of “finder” methods, it is too difficult to centralized.
What is your thoughts on this and if there is any white paper of best practice that you can point us to, we be most appreciated.

Answer 1

In answer to your technical questions, the only difference between descriptor level named queries and session level named queries is where the query is stored. Queries stored at the session level must have unique signatures, queries stored in the descriptor require unique signatures from other queries on the same descriptor but not queries on other descriptors or sessions.
Queries at the session level can be on any class, queries at the descriptor level must on that descriptor's class.
A ServerSession's query can be found from a ClientSession but queries added to a ClientSession will only be available to that ClientSession and will dispose when the ClientSession is released.
As to the questions about manageability it really is up to you to evaluate. If it is important to your organization that queries are moderated centrally then controlling them at the project level would provide for that. If that is not an important requirement then moving to a dynamic model would be less overhead, and headaches of having numerous people working on the source to and redeploying the same application repeatedly. But in general a combination of the two approaches, based on how often a particular query is used, would probably be best.
--Gordon