Kamna Jain wrote:
Hi All,
This question "might" be related to the thread that has been active in the past couple of days about the data model. We have a similar situation with the only difference being that we want to create lists or collections (like Groups) of certain pre- created Objects. The Object as a whole may/will belong to more than one such collection - which means that if we were to use a Document to link a Collection and its contents, then every document will have a COPY of the same object and this is definitely not desirable for good performance - Right?
Right. Any duplication (except for backup purposes) is bad.
So, in that case, we have 2 alternatives: 1) Use the techiniques used in XWiki to create Groups: each group has objects of class XWikiGroup with just one field that refers to the Member name. OR
Yes, this is somehow similar to the Foreign Key concept in databases, so it should be a good way to approach your problem.
2) Use XWiki.getHashmap() and add the Collection and its members to the hashmap (as the Key and Value resp.)
The XWiki API indicates that the option #2 must be used in xwiki when Objects can not be created. My Question is: -> Even though I could use option #1 and create objects and add them to the document that would represent the Collection, can I still use option #2 because I think that it will provide better performance. Am I right in my assumption? What should I do?
#2 is a bit faster, but it does not provide persistence. When the current request is over, that hashmap is gone. Given the fact that you probably have to store your data in a database, in the end you get almost the same performance as #1, but you have to reimplement what the XWiki platform already offers. When using a platform (any platform), you have to get used to the best practices of that platform; this is true for XWiki also: although some might be used to low level improvements of storage and SQL queries, and feel that they know better how queries should be written, XWiki offers a simple, high-level data model that should be used. The Google BigTable model was also received by some with dismay, since it doesn't follow the classical SQL principles. -- Sergiu Dumitriu http://purl.org/net/sergiu/