[xwiki-devs] XWiki Query Language & JCRStore status
Hi, devs. I committed first version of XWQL (or XQL) language to our sandbox (xwiki-query/xwql) for review. I worked ~2 last weeks for it. install info is in xwiki-query/README. Currently it works according my proposal[1], but it is quite easy to modify. It is not perfect, but it works and will be improved. You can test it via QueryManager. (for example in velocity: $xwiki.xWiki.store.queryManager.createQuery("select doc.fullName from Document as doc, doc.XWiki.ArticleClass as a where a.title like '%Launch'", "xwql").execute() ) plan for xwql (for fix in next week): * use xwiki-bridge instead of xwiki-core in xwql. (some methods in bridge are needed) * create query velocity service accessible like $services.query.xwql('...') (according Vincent's velocity services proposal [2]) * move xwiki-query maven module from sandbox to platform/components/ * move QueryManager component from xwiki-core to xwiki-query I would like to integrate xwql for hql in 1.6M2 (8 Sept) and improve it in RC if needed. JCRStore: old JCRStore with some modifications is partly working (save/load document is ok) on recent Jackrabbit, but missing some new stores and need redesign. plan: * create xwiki-store/jcr maven module in platform/components (at sandbox first) it have to depend on xwiki-core (but not reverse). Is it a problem for platform/components? * split JCRStore into components. (RepositoryFacory, SessionFactory, SessionPool, Stores, DAOs) * jcrstore will contains DefaultStores which will contain only business logic on data model, and use DAOs components for store/load data. DefaultStores will be reused in future HibernateStore to remove duplicating of code. * get rid of patched graffito-jcr-mapping (~ORM for JCR). it is old and unsupported. candidates: jcrom [3], jackrabbit-ocm (former graffito), simple hand-made annotation based mapping. I'll look at jcrom first. I already have some code and plan to work on it in sandbox, after finish with xwql-hql. I plan to create working version of JCRStore at the end of September. xwql on JCRStore will work only on JCRv2 implementation. [1] http://xwiki.markmail.org/message/uar73uglivj6fbbn [2] http://markmail.org/message/jwcjomrck3yo2kjq [3] http://code.google.com/p/jcrom/ -- Artem Melentyev
Hi Artem, On Aug 30, 2008, at 8:34 PM, Artem Melentyev wrote:
Hi, devs.
I committed first version of XWQL (or XQL) language to our sandbox (xwiki-query/xwql) for review. I worked ~2 last weeks for it. install info is in xwiki-query/README.
Currently it works according my proposal[1], but it is quite easy to modify. It is not perfect, but it works and will be improved.
You can test it via QueryManager. (for example in velocity: $xwiki.xWiki.store.queryManager.createQuery("select doc.fullName from Document as doc, doc.XWiki.ArticleClass as a where a.title like '%Launch'", "xwql").execute() )
plan for xwql (for fix in next week): * use xwiki-bridge instead of xwiki-core in xwql. (some methods in bridge are needed)
* create query velocity service accessible like $services.query.xwql('...') (according Vincent's velocity services proposal [2])
* move xwiki-query maven module from sandbox to platform/components/
* move QueryManager component from xwiki-core to xwiki-query
I would like to integrate xwql for hql in 1.6M2 (8 Sept) and improve it in RC if needed.
+1 to all that. So I'll try to work on the Velocity bridge thing (we need to decide if we go for this or for the annotation) tomorrow so that it's ready for you.
JCRStore: old JCRStore with some modifications is partly working (save/load document is ok) on recent Jackrabbit, but missing some new stores and need redesign. plan: * create xwiki-store/jcr maven module in platform/components (at sandbox first) it have to depend on xwiki-core (but not reverse). Is it a problem for platform/components?
Well new components should try not to use xwiki-core directly as much as possible. What's your need in xwiki-core?
* split JCRStore into components. (RepositoryFacory, SessionFactory, SessionPool, Stores, DAOs)
* jcrstore will contains DefaultStores which will contain only business logic on data model, and use DAOs components for store/load data. DefaultStores will be reused in future HibernateStore to remove duplicating of code.
* get rid of patched graffito-jcr-mapping (~ORM for JCR). it is old and unsupported. candidates: jcrom [3], jackrabbit-ocm (former graffito), simple hand-made annotation based mapping. I'll look at jcrom first.
I already have some code and plan to work on it in sandbox, after finish with xwql-hql.
I plan to create working version of JCRStore at the end of September. xwql on JCRStore will work only on JCRv2 implementation.
Ok so this means we can count on JCR full working for XE 1.7. I've already put it in the roadmap: http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap Thanks Artem for this feedback! -Vincent
Vincent Massol wrote:
...
JCRStore: old JCRStore with some modifications is partly working (save/load document is ok) on recent Jackrabbit, but missing some new stores and need redesign. plan: * create xwiki-store/jcr maven module in platform/components (at sandbox first) it have to depend on xwiki-core (but not reverse). Is it a problem for platform/components?
Well new components should try not to use xwiki-core directly as much as possible. What's your need in xwiki-core?
Well.. I need to load and store XWikiDocument, BaseObjects and so on in store :) So How can I not to use xwiki-core? Maybe, If we introduce some value objects (like in sandbox/org.xwiki.model), implement Stores and converters in xwiki-core and DAOs in xwiki-store then xwiki-store will need not xwiki-core and will use only value objects. The good thing is in this case we can reuse DAOs for new data model without much rewriting it (value objects will remain the same). But all data model manipulations (inside Stores) will stay in xwiki-core and need be refactored. And xwiki-store/jcr will be a small set of DAOs and JCR stuff, but more work on xwiki-core. I need to thinking about it. Maybe this is a better way. :) The big disadvantage I see is we can't use value objects in hibernate store without break the mapping. So migration needed, compatibility issues, etc. But the same disadvantage will be with new data model, I think.
...
-- Artem Melentyev
Hi, devs. status update:
plan for xwql (for fix in next week): * use xwiki-bridge instead of xwiki-core in xwql. (some methods in bridge are needed) done
* create query velocity service accessible like $services.query.xwql('...') (according Vincent's velocity services proposal [2]) velocity bridge is still absent.
* move xwiki-query maven module from sandbox to platform/components/ not done.
* move QueryManager component from xwiki-core to xwiki-query done. core/xwiki-query/manager
I'll try to implement "from doc.object(Class)" (seems easy) and "where doc.object(Class).property=something" (seems harder) xwql syntax before release, and commit it in xwiki-query/xwql Also I need one QueryManager refactoring for easy to add new languages via QueryExecuter components. After release I plan to improve xwql (javadocs, tests) and research in JCRStore topic: jcrom, DAO & value objects. -- Artem Melentyev
Hi, devs. status update: Artem Melentyev wrote:
I'll try to implement "from doc.object(Class)" (seems easy) and "where doc.object(Class).property=something" (seems harder) xwql syntax before release, and commit it in xwiki-query/xwql
done
Also I need one QueryManager refactoring for easy to add new languages via QueryExecuter components.
done
After release I plan to improve xwql (javadocs, tests) and research in JCRStore topic: jcrom, DAO & value objects.
In progress. to do for next week. also todo: Implement RamDAOs (store value objects just in hashmap) and DefaultStore and test it. Some thoughts about JCRStore: components: RepositoryProvider provides jcr.Repository and do shutdown. implementations: JackrabbitStandalone, ExoStandalone, JNDI, RMI, Webdav, etc. For beginning will be Jackrabbit and Exo standalones. SessionFactory getSession(workspace) createWorkspace(workspace) createWorkspace is implementation specific. not standardized. JcrDAOs (maybe extends jcrom.AbstractDAO) inject sessionFactory uses jcrom for mapping value objects There will be no pooling now, since pooling should be in JCR implementation (According Jackrabbit recommendations). However we can add it later in SessionFactory easily if needed. -- Artem Melentyev
Hi Artem, Artem Melentyev wrote:
Hi, devs.
status update:
Artem Melentyev wrote:
I'll try to implement "from doc.object(Class)" (seems easy) and "where doc.object(Class).property=something" (seems harder) xwql syntax before release, and commit it in xwiki-query/xwql
Are you handling all property types for properties ? If not which ones are currently supported ? What about custom mapping. Are you detecting this to write the HQL query differently ? Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Hi, Ludovic. Ludovic Dubost wrote:
status update:
Artem Melentyev wrote:
I'll try to implement "from doc.object(Class)" (seems easy) and "where doc.object(Class).property=something" (seems harder) xwql syntax before release, and commit it in xwiki-query/xwql
Are you handling all property types for properties ? If not which ones are currently supported ?
all except StringListProperty and DBStringListProperty. because they use other value property than "value". (textValue & list). This is easy to fix by adding 2 special cases.
What about custom mapping. Are you detecting this to write the HQL query differently ?
Not yet. But it is easy to add too: if there is a custom mapping then replace "BaseObject" to <XWiki.ClassName> and don't expand its properties. Correct? Thanks to point on this. Doing it now. Is it ok to include this in 1.6RC1? -- Artem Melentyev
On Sep 16, 2008, at 5:43 PM, Artem Melentyev wrote:
Hi, Ludovic.
Ludovic Dubost wrote:
status update:
Artem Melentyev wrote:
I'll try to implement "from doc.object(Class)" (seems easy) and "where doc.object(Class).property=something" (seems harder) xwql syntax before release, and commit it in xwiki-query/xwql
Are you handling all property types for properties ? If not which ones are currently supported ?
all except StringListProperty and DBStringListProperty. because they use other value property than "value". (textValue & list). This is easy to fix by adding 2 special cases.
What about custom mapping. Are you detecting this to write the HQL query differently ?
Not yet. But it is easy to add too: if there is a custom mapping then replace "BaseObject" to <XWiki.ClassName> and don't expand its properties. Correct?
Thanks to point on this. Doing it now.
Is it ok to include this in 1.6RC1?
Yes. RC1 is planned for be released either tomorrow or next Monday (more likely) depending on how fast we finish WYSIWYG editor and rendering issues. Thanks -Vincent
Artem Melentyev wrote:
...
What about custom mapping. Are you detecting this to write the HQL query differently ?
Not yet. But it is easy to add too: if there is a custom mapping then replace "BaseObject" to <XWiki.ClassName> and don't expand its properties. Correct?
Ok. Found. It is slightly more complicated: I need to join BaseObject.id=<XWiki.ClassName>.id and use <XWiki.ClassName> for access to object properties.
Thanks to point on this. Doing it now.
Is it ok to include this in 1.6RC1?
-- Artem Melentyev
Artem Melentyev wrote:
Hi, Ludovic.
Ludovic Dubost wrote:
status update:
Artem Melentyev wrote:
I'll try to implement "from doc.object(Class)" (seems easy) and "where doc.object(Class).property=something" (seems harder) xwql syntax before release, and commit it in xwiki-query/xwql
Are you handling all property types for properties ? If not which ones are currently supported ?
all except StringListProperty and DBStringListProperty. because they use other value property than "value". (textValue & list). This is easy to fix by adding 2 special cases.
What about custom mapping. Are you detecting this to write the HQL query differently ?
Not yet. But it is easy to add too: if there is a custom mapping then replace "BaseObject" to <XWiki.ClassName> and don't expand its properties. Correct?
Well you have to check if the property is custom mapped because you can have a mix.. I think there are some apis for that..
Thanks to point on this. Doing it now.
Is it ok to include this in 1.6RC1?
Since xwql query is experimental I think you can put it in the state it is at release time Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
participants (3)
-
Artem Melentyev -
Ludovic Dubost -
Vincent Massol