25 May
2008
25 May
'08
8:18 p.m.
Hi, Vincent.
Vincent Massol wrote:
2) Only use the methods that you need now and add
methods as they are
needed in the future. For ex if there's no need right now for named
queries we should probably not use it (Of course we should think about
all use cases so that we have a solution should they arise).
Ok
3) Why do we still need a QueryPlugin? I don't
think it's needed
anymore with the QueryManager. For me the Query Plugin should be
modified to be one of the Query implementation (HQL, XPath - this one
-, JCRSQL, etc).
We need also some secure query (ex: QueryPlugin's xpath for Hibernate is
secure, so it checks "query" right if query contains some non public
fields), but yes, it can be some language in QueryManager.
4) I'd really like that we try to remove any
velocity-specific API so
that we have only 1 Java API for all. Maybe we can introduce some
velocity tools to handle the cases where you think it is required.
What would be those cases?
Main issue are check rights for returned documents and shorter API (ex:
QueryManager#xpath(""), Query#setParams(List)).
We can expose QueryManager as the QueryPlugin (ex: xwiki.getQuery()
returns QueryManager, without plugin api), add some shorter methods and
protect #createQuery by our @Programming annotation.
WDYT?
5) Why do we need to write Language.HQL.name() and not
Language.HQL?
Because "Language" is Java5 enum, but QueryManager#createQuery require
String (for adding new Languages without modify the Language enum).
Ok. This is not good, so I propose to:
public interface Query {
static final String HQL = "hql";
static final String XPATH = "xpath";
...
}
And use qm.createQuery("...", Query.HQL);
As well as in the JCR. (JCR don't use enums because targets at Java1.4)
--
Artem Melentyev