24 Apr
2008
24 Apr
'08
8:59 p.m.
Hi,
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.
Thanks
Sachin
-----
http://www.assembla.com/wiki/show/sachin_mittal about me:
--
View this message in context:
http://www.nabble.com/Relating-classes-in-xwiki-tp16851540p16851540.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
25 Apr
25 Apr
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
12:42 p.m.
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.
11:59 a.m.
On Thu, Apr 24, 2008 at 8:59 PM, Sachin Mittal <sjmittal(a)gmail.com> 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
12:58 p.m.
New subject: [xwiki-devs] Re lating classes in xwiki
Thanks Jean-Vincent,
Jean-Vincent Drean-2 wrote:
You response really helped me in understanding use cases 1 and 2.
Say I was using case 3 and now would like to use switch to case 2.
As we are aware that we cannot delete a property once added, so the db list
fields to refer parent class objects would be redundant, and would be empty.
I hope this would not cause any perf issues as you have mentioned in case 3.
Also in case parent class is referred using db list and if parent value (the
one used for reference) changes, is there anyway to handle this change in
child objects too. Would this break the relationship.
I think I would restrict db list to user list only, but just in case I have
a use case where a class is child of some class and also associated to some
other class, I can make the child document child of one of the parent
document, but for other class I would have to use db list. So understanding
the name changes of associated object is important for point 3.
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-tp16851540p16894715.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
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.
5 May
5 May
9:38 p.m.
New subject: [xwiki-devs] Re lating classes in xwiki
Sachin Mittal wrote:
Thanks Jean-Vincent,
Jean-Vincent Drean-2 wrote:
>> 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.
>
>
The problem was solved with the AjaxSuggest. Another problem is the fact
that the query has more joins.
You response really helped me in understanding use
cases 1 and 2.
Say I was using case 3 and now would like to use switch to case 2.
As we are aware that we cannot delete a property once added, so the db list
fields to refer parent class objects would be redundant, and would be empty.
I hope this would not cause any perf issues as you have mentioned in case 3.
If you don't display the field, it won't be a problem.
Also in case parent class is referred using db list
and if parent value (the
one used for reference) changes, is there anyway to handle this change in
child objects too. Would this break the relationship.
I think I would restrict db list to user list only, but just in case I have
a use case where a class is child of some class and also associated to some
other class, I can make the child document child of one of the parent
document, but for other class I would have to use db list. So understanding
the name changes of associated object is important for point 3.
Thanks once again.
When renaming a document, the platform searches for links to that
document and proposes to update them. Currently, only the parent field
and wikilinks (inside the textual content, not in objects) are updated,
so if you use #2, all relationships could be preserved.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
6031
days inactive
6042
days old
5 comments
4 participants
participants (4)
-
Guillaume Lerouge -
Jean-Vincent Drean -
Sachin Mittal -
Sergiu Dumitriu