30 Aug
2008
30 Aug
'08
8:34 p.m.
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
30 Aug
30 Aug
9:56 p.m.
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
11:19 p.m.
Vincent Massol wrote:
...
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.
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? > ...
--
Artem Melentyev
8 Sep
8 Sep
1:01 a.m.
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
14 Sep
14 Sep
9:32 p.m.
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
16 Sep
16 Sep
9:12 a.m.
Hi Artem,
Artem Melentyev wrote:
Hi, devs.
status update:
Artem Melentyev wrote:
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
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
5:43 p.m.
Hi, Ludovic.
Ludovic Dubost wrote:
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.
status
update:
Artem Melentyev wrote:
Are you handling all property types for properties ? If not which
ones
are currently supported ? 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
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
5:54 p.m.
On Sep 16, 2008, at 5:43 PM, Artem Melentyev wrote:
Hi, Ludovic.
Ludovic Dubost wrote:
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.
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
status
update:
Artem Melentyev wrote:
Are you handling all property types for properties ? If not which
ones
are currently supported ? 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
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?
6:10 p.m.
Artem Melentyev wrote:
...
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.
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
8:28 p.m.
Artem Melentyev wrote:
Hi, Ludovic.
Ludovic Dubost wrote:
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.
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..
status
update:
Artem Melentyev wrote:
Are you handling all property types for properties ? If not which ones
are currently supported ?
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
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?
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
6057
days inactive
6074
days old
9 comments
3 participants
participants (3)
-
Artem Melentyev -
Ludovic Dubost -
Vincent Massol