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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
