[MGNLDATA-88] Samples for hierarchical data types have incorrect hierarchy Created: 16/Nov/09 Updated: 04/Nov/15 Resolved: 04/Nov/15 |
|
| Status: | Closed |
| Project: | Magnolia Data Module (closed) |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Boris Kraft | Assignee: | Philipp Bärfuss |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Magnolia 4.2 RC 2 |
||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Date of First Response: |
| Description |
|
The samples for the hierarchy ("Big-Flower-Inc") seem to have the wrong hierarchy. The defined hierarchy is as follows: Company
As you can see, this doesn't allow to create employees within a department. It would make more sense to have the following hierarchy: Company
The sample content should also reflect this different structure. |
| Comments |
| Comment by Jan Haderka [ 16/Nov/09 ] |
|
It was never the intention of the sample. The idea I had was to show two different ways how to store the data: in a subgroups (permanent vs. temporary employees) and flat (departments), not to show that you can build arbitrary deep structure. You should look at that sample in connection to the documentation which explains it. |
| Comment by Boris Kraft [ 16/Nov/09 ] |
|
Thanks. Meanwhile I saw the docs. I think the initial example should be more intuitive. When I first saw it it was immediately clear to me that the sample hierarchy must be wrong. That is not the feeling I want to give people when they look at the sample - and they should not need to read the docs to understand it. I suggest that we rethink the example. We can always make more complex ones in the docs. |
| Comment by Jan Haderka [ 16/Nov/09 ] |
|
The part of the problem is that when you look at this example you immediately jump to conclusion and think of big companies where every employee have to belong somewhere (I agree the name of the sample is wrong as it leads to such conclusion). Lots of small to middle sized companies do not necessarily put each employee into the department, or one employee can belong to multiple departments, working part time for each, etc. For this I would be fine to extend the example so from each employee dialog you can assign them to 1..n departments, but I still don't think the example would be better by moving employees into deeper hierarchy. Another, IMHO important aspect is to show that you don't need to match exactly company structure, you need to flow with the data. If I'm interested in the employees, I want to be able to browse them through w/o having to go through many levels of hierarchy. I only need to be able to find out how they relate to company hierarchy. ... you see this kind of think every day when trying to browse image or music collections ... the categorization is nice to have things organized, but is pain to work with when all you want to is browse. For this reason the tagging is becoming so popular as it doesn't force the hierarchy. Similarly I would prefer to "tag" (link) employee w/ the department, rather then to have them in the hierarchy. And last aspect of this is resilience of the structure. Companies reorganize their departments regularly and move employees between them. Having employees softly linked to their departments makes this more manageable (One can create new departments and assign employees to them while the old structure is still in place and searchable, and migrate step by step, rather then changing everything in one big bang op). But then again, this is all matter of personal opinion. If you feel that it is difficult to explain to customers, please come up with the structure and elements for the example that would show both (hierarchical and flat) part of the storage and can be used to explain the differences and we can re-work the sample, let's just try to not make it overly complicated (i.e. if departments are confusing, let's drop them all together, or if we keep them, let's drop the permanent/temporary distinction so we keep it light). |
| Comment by Boris Kraft [ 16/Nov/09 ] |
|
I think that we already have a flat example with the Address Book. So this example here could focus on the hierarchical part. I understand much of what you say, however the sample shouldn't try to solve these organizational issues; it should be something that is easy to grasp, fulfills expectations and somehow seems to convey the benefit of hierarchical data management. As you rightly point out, the issue of putting employees in a hierarchy is in practice more complicated; and tags might be better for some scenarios. Also, adding a relation (from employee to department) makes sense in some use-cases, while for others, having the hierarchy explicit might be more natural. Our goal should be to come up with an example where managing data in the hierarchy provides immediate benefit compared to management in a relational database. One example is that in a relational DB, you need to set the relationship explicitly. In the hierarchy, if you add an employee below the "sales" dept. it is obvious the employee belongs to the sales department, and no such relationship needs to be maintained separately. BTW - if anybody has a great example for this, let us know. |
| Comment by Michael Mühlebach [ 04/Nov/15 ] |
|
Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes. |