25 Apr
2008
25 Apr
'08
11:39 a.m.
Hi Sachin,
Using xwiki class editor we can create classes and package them as
application. Classes can also have an entity
relationship among themselves.
I have few question on how can we relate classes in xwiki. Let me start by
posting a simple example:
Say our application has two classes Product and Review. Relationship
between
them is a product can have multiple reviews.
Now I can relate these classes in following way:
1. Create a product document and add the product
object to it. All the
reviews for that product are also added to that product document as review
objects. Thus I have grouped reviews to a product.
2. Create a product document and add the product object to it. For each
review for that product created a review document and add review object to
that review document and make review document child of product document.
Thus I have arranged reviews as children of a product.
3. In the review class add a db list field, which refers to objects of
product class. While creating a review object choose the right product name
from the list. Thus reviews are associated to a product.
Thus you can see that in each of the three ways I have related two classes.
Only difference is different ways of storing them. (again presentation
still
can be same and I am here interested in optimal storage strategy only).
So I would like to know which of the above three is the best way of
relating
classes. Are there any more ways of achieving the relationship I talked
initially?
I would like to know from people who have been developing complex
applications involving relationship between several xwiki classes as what
would be the best way of arranging the use case just described.
There are a number of factors to consider when creating relationships
between classes in XWiki. The most important thing to think about is :
what's the purpose of your application ? How many people will be using it ?
Should it be able to scale ?
1. Use case 1) -> that's what I've done for topics in the Bulletin Board
for instance. It's an easy way to create a direct & necessary relationship
between 2 classes. However it is really hard to break this relationship
afterwards. Therefore this use case should be reserved for strong
relationships that do not involve more than 2 classes (topic + posts in this
topic are a good example I think)
2. Use Case 2) -> that's how the relationship between categories & topics
is organized in the Bulletin Board application. The main benefits of this
approach are flexibility and scalability. Since each object is held in its
own document, you do not need to care about scalability -> you won't have
real big stuff hanging around in your DB (the way you would with a document
with 50 objects appended + 76 revisions). However it's a bit harder to write
the HQL queries afterwards. You can always rewrite parent-child
relationships, and there's no limit to the number of relationships you can
build Parent 1 -> Children [1,2,3] -> grandchildren [1,2,3,4,5,6] etc...
3. Use case 3) -> I've never used it personally but it might fit well in
other use cases. It can be useful when you want to build a complex network
of classes (if one class relates to more than one other). Actually to
address this use case the best thing to might be to have some kind of
specific metadata at the document level (like tags, but implemented in the
core rather than thru objects). That's a trail Vincent has been thinking
about lately, so I expect to see more about it in the upcoming discussions
about XWiki's architecture.
So basically there's no "best way" to build those relationships I think, it
really depends on what you want to achieve and whether you want to be able
to scale.
Guillaume