liveBook · Manning

Unique constraint

As explained in Building User-Friendly DSLs

A constraint that detects sufficiently similar neighboring or related things whose names are too similar or equal.

A uniqueness constraint rejects DSL content whose neighboring or related names are sufficiently similar to collide after generation. It reports the violation as an issue for domain experts to repair. section 9.4 section 9.3.6

Implement the constraint by:

  • Converting the current attribute name to camel case. section 9.3.6
  • Finding other attributes in the containing record whose normalized names match, while excluding the current attribute. section 9.3.6
  • Adding an issue that lists the similarly named attributes. section 9.3.6
  • Applying the ImposeConstraints strategy before strengthening generation to handle faulty content. section 9.4

Colliding attribute names

Attributes named “foo bar” and “Foo Bar” both normalize to fooBar. Generated record code assigns fooBar twice with incompatible types, while the Runtime form shows confusing fields. The constraint reports the similarity instead of allowing the collision to pass silently. section 9.3.6

How Building User-Friendly DSLs covers it

How deep it goes
Descends to AST navigation, camel-case comparison, issue construction, and mitigation strategy, but not a generalized constraint framework.
Examples
Demonstrates “foo bar” and “Foo Bar” colliding as fooBar in generated record code and Runtime form fields.
What you can do after
Build it from scratch by normalizing names, comparing sibling attributes, and emitting actionable domain-expert issues.
How it connects
Connects ASTs, domain-specific languages, code generators, Runtime interfaces, and constraint validation.

Also explained in

Compare how 7 books explain unique constraint →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Building User-Friendly DSLs. The section links point to the parts of the book it draws on.