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/