Expected behavior of Template AttributeDefinition with inconsistent sources

Cantor, Scott cantor.2 at osu.edu
Thu Jul 18 12:49:20 EDT 2019


I poked some more and there's always been support for turning empty or null values into "" or null as input to the Template. That would still produce the literal $mail output, so that's definitely a "possible" result to guard against if in fact that possibility exists in the source data.

But as I said, EmptyAttributeValue wrapping a null or empty string is still treated as 1 value from the point of view of a count. And that was always accepted as a means of having equal counts.

In practice that means LDAP result sets and JDBC result sets fed into Template are likely to do different things if the input attribute is absent, throw on the former and spit out that literal text in the latter case. LDAP doesn't create those empty value objects but JDBC must because it's tabular data.

I don't think the docs make any of this clear of course, since "same value count" means different things to different people.

V4 will change this some more by carving out an allowance for "no values at all", as in the LDAP case, and causing that to be ignored, and I already documented that as a change in behavior. I just felt it was convenient to allow that, and punt to, as Peter said, guarding the template with a conditional. It also has the nice effect of making the result consistent in those two example cases.

But the conditional is still needed if you have the possibility of a null/empty value being present as in JDBC, and that should be true dating back to every version. So I can't explain the observation unless the 3.3 case was LDAP and the 3.4 case was JDBC or some other case. That would explain the observed difference though.

-- Scott




More information about the users mailing list