Thanks Guillaume ,
Guillaume Lerouge wrote: > > > 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 ? > Yes hope is that many people use this application and surely it should scale. Guillaume Lerouge wrote: > > 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) > I think I would restrict this relationship when I would have only two classes and for the child class there would not be many objects. Guillaume Lerouge wrote: > > 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... > I think is this best way to arrange classes and their objects. I would use this as much as I can, and I think this would scale. Yes search part would be tricky here, but I think can be figured out afterwards. Guillaume Lerouge wrote: > > 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. > I think I would use this when classes related to two or more classes. Like in current example product can have multiple reviews and each user can write multiple reviews. So review class is linked to product class and user class. I have one doubt in relating classes using db list, say if later the product name itself changes then would the relationship break? One way to address is to use the property that never changes. Also in the current application I am developing most classes are in a parent child kind of relationship with some having additional relationship to the user class. So we can use the UserList property for such relationship. Again I have a doubt that of later the user name itself changes (highly unlikely, but still..) would the relationship break. Guillaume Lerouge wrote: > > 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. > Thanks once again! Sachin ----- http://www.assembla.com/wiki/show/sachin_mittal about me: -- View this message in context: http://www.nabble.com/Relating-classes-in-xwiki-tp16851540p16894702.html Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
