[MDSAL-120] Duplicate length restriction checking Created: 08/Dec/15  Updated: 09/Mar/18  Resolved: 15/Dec/15

Status: Resolved
Project: mdsal
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Robert Varga Assignee: Robert Varga
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


External issue ID: 4743

 Description   

Migration to new types has introduce a regression in length enforcement, where the same length constraints are being enforced in Builders where the leaf is derived from a restricted type.

This is evident in GBP's health.yang, where we see the following:

private static void check_descriptionLength(final String value) {
final int length = value.length();
if (length >= 1 && length <= 4096)

{ return; }
throw new IllegalArgumentException(String.format("Invalid length: %s, expected: [[1‥4096]].", value));
}

public FaultBuilder setDescription(Description value) {
if (value != null) { check_descriptionLength(value.getValue()); }
this._description = value;
return this;
}

where Description already does:

private static void check_valueLength(final String value) {
final int length = value.length();
if (length >= 1 && length <= 4096) { return; }

throw new IllegalArgumentException(String.format("Invalid length: %s, expected: [[1‥4096]].", value));

@ConstructorProperties("value")
public Description(java.lang.String _value) {
if (_value != null)

{ check_valueLength(_value); }

Preconditions.checkNotNull(_value, "Supplied value may not be null");

this._value = _value;
}

While this does not affect functionality, it produces redundant code and reduces performance.

This seems to be coming from BindingGeneratorUtil.getRestrictions(), which needs to check against the base type to see if the restrictions are different. If they are not, it should report empty restrictions.



 Comments   
Comment by Robert Varga [ 08/Dec/15 ]

https://git.opendaylight.org/gerrit/31023

Comment by Robert Varga [ 08/Dec/15 ]

As it turns out, this is not a regression as current Lithium generates same duplicate enforcers.

The patch below fixes only the class instantiation checks, where the enforcement hierarchy moves across the class hierarchy stack.

Further investigation of BuilderTemplate.xtend needs to be done, leading to that template properly recognizing the case when the referenced type already performs the enforcement.

Comment by Robert Varga [ 15/Dec/15 ]

https://git.opendaylight.org/gerrit/31032

Generated at Wed Feb 07 20:08:41 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.