add relative key link for ConflictsWith field

[kdudkov]

when you have a list (f.e. in field list) of objects, with conflicted fields inside (f.e. field1 and field2), you can't use ConflictsWith, because you have to set full path to conflicted field, but it contains index (f.e. list.0.field1).
I've relative path for this case in form of ..field2

[hashicorp-cla]

All committers have signed the CLA.

[radeksimko]

Hi @kdudkov
thank you for the PR. Sadly I will have to close it for a couple of reasons I'll try to outline below.

• We are in early planning stages of transitioning the SDK from "0.11 state" to 0.12, which includes transitioning to a new addressing scheme. While the dot-based addressing scheme is in use by the SDK (and hence providers) today, it is practically phased out from core itself and there's a thick layer of code providing backward compatibility, so that these providers didn't have to rewrite all addresses just to become compatible with 0.12. This scheme however has a few flaws and that's why it's being replaced with the scheme contained within the new type system in use by 0.12 - cty. I will explain more details about differences below.
• There are risks associated with relative addressing:
  • Outdated addresses: Most providers undergo active development where many developers of different backgrounds (skills and knowledge of the codebase) change and refactor schemas many times over a long period. While the risk of forgetting to update addresses exists in the current (absolute) scheme, the outcome is less likely to lead to confusion as wrong absolute address will lead to a field which doesn't exist, rather than "parent field called X" which may exist, but it may not be what the developer intended after refactoring.
  • It makes it easier to build very complex and deeply nested schemas, which tend to be hard to understand generally and then present a challenge in ongoing maintenance. We realize that deeply nested schemas are sometimes still necessary, but we'd like to better understand these cases and help developers to avoid them. Support the pseudo dynamic type #248 Add support for maps with non-primitive types (rich / object map support) #62 helper/schema feature: nestable resources #57 represent some examples of how we may address this problem going forward.

---

The (current) dotted addressing scheme

• stores addresses as []string, or even string which makes it difficult to trace where address is being passed or mutated
• has no consistent story about which layer of code can/should check whether the address exists or is even valid, leaving most addresses actually unchecked until the very last minute.
• has no consistent story about how to walk through "steps" in the address and map it back to the schema or data (or both)
• makes it practically impossible to address items within a set
• can produce ambiguous addresses as it doesn't differentiate between keys of maps/objects and indexes of sets or lists (everything is separated by dots)

The new scheme provides us much more solid groundwork to construct addresses in much safer and unambiguous way.

---

I'm assuming you're working with deeply nested schemas and your feedback would therefore be valuable at any of the mentioned issues #248 #62 #57 . Alternatively I invite you to open a new issue if you feel that your problem can't be addressed by any of those.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.