JBO DebugOutput Question

Question

We're having some trouble with our views auto-querying when we attempt to add a new row. It's a JClient app that doesn't initially query any rows. We turned on jbo.debugoutput=console to get more information on the problem. Now we have a couple of questions on what some of the debug messages mean. The entries below were generated when we brought the form up and went into Find mode. Here is a snippet from the console:
[751] Changing iterator range size from :1 to :1000
[752] Column count: 13
[753] ViewObject: PaymentTermsView Created new QUERY statement
[754] PaymentTermsView>#q computed SQLStmtBufLen: 999, actual=982, storing=1012
[755] SELECT * FROM (SELECT PaymentTerms.PAYMENT_TERM,
       PaymentTerms.LAWSON_TERM_CODE,
       PaymentTerms.DESCRIPTION,
       PaymentTerms.IP_TERM_CODE,
       PaymentTerms.DISCOUNT_PCT,
       PaymentTerms.DISCOUNT_DAYS,
       PaymentTerms.NET_DAYS,
       PaymentTerms.ACTIVE_FLAG,
       PaymentTerms.CREATE_SOURCE,
       PaymentTerms.CREATE_DATE,
       PaymentTerms.LAST_UPDATE_SOURCE,
       PaymentTerms.LAST_UPDATE_DATE,
        PaymentTerms.PAYMENT_TERM as SORTED
FROM PAYMENT_TERMS PaymentTerms
WHERE PaymentTerms.ACTIVE_FLAG = 1
union all
SELECT null as PAYMENT_TERM,
       null as LAWSON_TERM_CODE,
       null as DESCRIPTION,
       null as IP_TERM_CODE,
       null as DISCOUNT_PCT,
       null as DISCOUNT_DAYS,
       null as NET_DAYS,
       null as ACTIVE_FLAG,
       null as CREATE_SOURCE,
       null as CREATE_DATE,
       null as LAST_UPDATE_SOURCE,
       null as LAST_UPDATE_DATE,
        -1 as SORTED
FROM dual) QRSLT  ORDER BY SORTED asc
[757] Bind params for ViewObject: PaymentTermsView
[758] EntityCache:add WARNING - ignoring row with no primary key
[759] $$added root$$ id=-2
[760] EntityRowSetImpl's jbo.assoc.consistent = true (1) This query is used as the lookup for a Combobox binding and we need a blank row to provide a null selection, so that is the reason for the union.
What we are most curious about is what the meaning of lines 758, 759, and 760 is.
I suspect that line 758 is caused by the unioned null row since it wouldn't have a valid primary key.
Also, I would expect that line 759 might be ADF creating a row in the Entity cache for the null row and attempting to generate a temp id if the primary key was an attribute type of DbSequence, but that isn't the case here.
Line 760 seems to be enforcing/setting the association consistency property for the view, but most of the other views don't have this entry. Seems like it might have been due to the Entity the view is based on having a Composition Association to another Entity, but that isn't the case for this view.
Any help understanding these entries would be greatly appreciated.
Thanks
Erik

Answer 1

After further review, I have discovered that line 760 does indeed correlate to the Composition setting of the Association. It also appears to come in the beginning when setting up the view's query, so it actually goes with the next view in our log, which does have a Composition Association.
Also, I believe my assessment of line 758 is correct in that it is caused by the null row. This could explain why we have noticed that the trick of including a queried null row doesn't always work for some comboboxes. In some cases the null row still doesn't show in the list. Now, I believe that this is because those Views are based on an Entity. The Entity most contain the primary key for a row in order to cache it. For the null row, there is no valid primary key, so the cache ignores it. This would mean that the combobox wouldn't show the null row, because it doesn't get it back from the Entity cache. For the comboboxes based on Views that are ViewOnly, they would show the null row because the View cache has no requirement for a valid primary key. This is only speculation at this point. I'll try and confirm.
If the above answers are correct, then we really only need clarification on what line 759 means.
Erik