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

On Thu, Apr 24, 2008 at 8:59 PM, Sachin Mittal <[email protected]> wrote:

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.

This way is the simpliest one, cons : - not scalable since document load/save speed depends on the number of objects it holds. - objects cannot be queried from the public API (meaning no ordering on field values for example) - notifications (by email for example) are hard to write (which object has been modified in this save ?)

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.

Best way to do it imho, pros : - scalable - no need to create author, date, title, etc fields in your Review class - methods needed to get relationships are already present in the Document API (get childs, parent) - allow complex queries like ordering the reviews by some criteria (creation date, mod date, author, etc) - easy to write fine-grained notifications (review creation/modification/deletion)

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.

I've tried this in the past but I had some perf issues with the db list displayer. It also appeared that choosing an item in a long list when it was possible to imply the parent from the parent sheet wasn't effective from the user POV. BTW this behavior can be emulated with some custom parent displayer. Hope this helps, -- Jean-Vincent Drean