[MAGNOLIA-3482] References support is broken Created: 24/Dec/10 Updated: 19/Dec/16 Resolved: 04/Nov/15 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | core |
| Affects Version/s: | 4.4.2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Magnolia International | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
| Date of First Response: |
| Description |
|
Not sure exactly since when but info.magnolia.cms.core.AbstractContent#setNodeData(String name, Content value) changed its behavior and forces a property creation of type String, whereas setNodeData(String name, Object value) would create a "real" JCR reference. Currently causing the forum to break (although I'll work around it easily) since its nodetypes enforces the use of jcr references. Our string-based references are probably better off replaced with weak references (introduced in jcr 2.0), but to keep their support, we should then have explicit methods/doc to allow both string-based and "real" references to co-exist. |
| Comments |
| Comment by Philipp Bärfuss [ 18/Jan/11 ] |
|
Both the methods should save a uuid String. This is currently the way to work with "references" in Magnolia. So setNodeData(name, content) works as expected. So we should probably introduce a setNodeData(String name, Content value, boolean softlink), while softlink is true by default. |
| Comment by Philipp Bärfuss [ 18/Jan/11 ] |
|
We are finalizing 4.4.2 hence I am moving this issue to 4.4.3. |
| 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. |