<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 2/15/17 8:25 PM, Cantor, Scott
wrote:<br>
</div>
<br>
<br>
<br>
<blockquote cite="mid:99906AC5-E81C-4878-9AA3-6C0391B0E999@osu.edu"
type="cite">
<pre wrap="">
So I do think it's totally undefined,</pre>
</blockquote>
<br>
Well, I think *currently* it is defined (although maybe not clearly
enough) and doing what the wiki and Javadocs say, as evidenced by
the language around the same number of values requirement. Reading
the code, it's pretty clear it's doing what is intended, rightly or
wrongly.<br>
<br>
<br>
<blockquote cite="mid:99906AC5-E81C-4878-9AA3-6C0391B0E999@osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">It's fine if you've got just 1 dependency (with either 1 or many values). It's also fine if you've got multiple dependencies
with 1 value each (or maybe *at most* 1 value each).
</pre>
</blockquote>
<pre wrap="">
I would imagine it works if you have 5 input attribute definitions that supply material for 5 SourceAttribute expressions and all have the same value count. At least, I would think it might.</pre>
</blockquote>
<br>
By "fine" I meant "makes sense", in a practical way. It certainly
functions without error in all the cases. Except for the special
case I mention below, it just doesn't strike me as something one
could typically practically and reliably use in the
multi-input+multi-value case. <br>
<br>
<br>
<blockquote cite="mid:99906AC5-E81C-4878-9AA3-6C0391B0E999@osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">But the multiple dependencies with multiple values case seems an issue to me. Say you have dependency d1 with values
(foo, bar, baz), and d2 with (x, y, z), with each set of values in that iteration order. As near as I can tell, the template is
going to get executed 3 times, with the following values:
(foo, x)
(bar, y)
(baz, z)
</pre>
</blockquote>
<pre wrap="">
I think that's the case I allude to above. And I would contend that's sensible if it's what your mental picture happens to be. It makes more sense for AttributeDefs than DataConnectors.
</pre>
<blockquote type="cite">
<pre wrap="">Since the value ordering is arbitrary, that doesn't seem very useful.
</pre>
</blockquote>
<pre wrap="">
It's not arbitrary. Attributes are an ordered set of values, very explicitly. We actually broke that pre-3.0 until I caught it and realized what we'd done. The reason of course is modeling SQL result sets out of DataConnectors, maintaining NULL values inside those sets, etc.</pre>
</blockquote>
<br>
Yes, I misspoke. The ordering is not arbitrary in a technical
sense. But the way the values are combined only makes sense if you
know and/or control the order of *all* the input values. I was
trying to convey that the ordering is often going to be
quasi-arbitrary from the *user standpoint*.<br>
<br>
I forgot about the SQL case, so I guess it works ok there if you
write the SQL for all the inputs so that they are ordered just so,
and combine in the desired way (and are all guaranteed to produce
the same number of values). I guess explicit ordering may be
possible for some other cases too, like static.<br>
<br>
But I don't think that model works for the general case, like LDAP
or others, which produce values in orderings unknown to, and
uncontrollable by, the user. That was my point, and for that reason
it seems problematic that it does it that way unconditionally and by
default. It should perhaps only do that via explicit config.<br>
<br>
<br>
<blockquote cite="mid:99906AC5-E81C-4878-9AA3-6C0391B0E999@osu.edu"
type="cite">
<pre wrap="">Thoughts?
</pre>
<pre wrap="">
I think virtually anything might be possible or useful, but once Rod has blown Dependency to the hellpit it belongs in, we have a shot at actually controlling what's actually possible to specify.</pre>
</blockquote>
<blockquote cite="mid:99906AC5-E81C-4878-9AA3-6C0391B0E999@osu.edu"
type="cite">
</blockquote>
<br>
<br>
True. It might be wise to consider the default behavior for the
"simple" cases as distinct from the "advanced" multi-value cases.
For the latter one should maybe have to explicitly pick an output
"combining algorithm", be it the current behavior, or a full
Cartesian set or concatenation or whatever.<br>
<br>
Fwiw, when I initially started to comment on Peter's suggestion,
before I got off on the above tangent, I was going to comment/ask:
"What would it do if the number of values in the inputs is NOT the
same?". I was going to say that the only 2 obvious sensible things
would be: 1) only iterate as many times as the smallest number of
values. This would result in some values not being used. This is
what Python zip() does. 2) iterate as many times as the greatest
number of values, and use a null/empty value for cases where a
specific input's values are exhausted. Neither really seems
ideal... I guess it could also: 3) cycle on the inputs which are
less than greatest number (treat each input like a cyclical
"generator"). But at that point my brain starts to melt.<br>
<br>
<br>
</body>
</html>