Autoedge - "IgnoreBuffers" vs "BufferNoFill&q

I have a question regarding these two context values

This smells like the OERA version of global variables

that can be used to prevent a pds temp-table from

being filled, by setting buffer's FILL-MODE =

"NO-FILL".

I think its a very fragile construction to use a global context variable, specified at the highest layer of the architecture, to ignore buffers in the bottom layer of the architecture. What if by accident this buffer is used in another da-object?

Obviously the da-interface is not complete, since it requires a buffer-ignore parameter in its contract. But I guess the designers didn't like passing this information all the way down to the da-instance, right?

I think its a very fragile construction to use a

global context variable, specified at the highest

layer of the architecture, to ignore buffers in the

bottom layer of the architecture.

Well, for a BE to be re-usable in different circumstances, I think it should be enough flexible for the client requester to be able to specify some buffers to not be filled. If they are not needed, why include the overhead of filling them ?

>What if by accident this buffer is used in another da-object?

Can you explain how can this unfilled buffer be used inside another BE's DAO ?

Which layer of the architecture can call another DAO without going through the DOA's BE ?

Well, for a BE to be re-usable in different

circumstances, I think it should be enough flexible

for the client requester to be able to specify some

buffers to not be filled. If they are not needed, why

include the overhead of filling them ?

Sure, I agree with that, but I don't agree with the way it's requested. If the da-object is smart enough to work with dynamic buffers, why can't it check for the existence of fields and tables? The caller can provide the structure it wants, the datasource can try to populate the things it knows.

Btw: everything is easy right now, since there is no real mapping between physical database tables and in memory temp-tables.

Can you explain how can this unfilled buffer be used

inside another BE's DAO ?

Which layer of the architecture can call another DAO

without going through the DOA's BE ?

You're right about that observation. I was thinking about a task that calls different BE's. For all these sub tasks the context is the same. Here it's 19:26 and it has been a long day, so I don't have enough inspiration to find an example ;-(

I have a question regarding these two context values

that can be used to prevent a pds temp-table from

being filled, by setting buffer's FILL-MODE =

"NO-FILL".

Here is what I understand from the code:

"IgnoreBuffers"

- Is used in fetchWhere(daCar.p) AFTER data-sources

has been attached. Why attach data-source if the tt

isn't gonna be filled ?

- Must be duplicated in each daXXX.p

- Also used for save operation in

commitChanges(daSupport.p)

"BufferNoFill"

- Used in addDataSource(daSupport.p). If "NO-FILL",

the DSO is not instantiated and no attach-data-source

occurs.

- All daXXX.p use the support routine

"addDataSource", so the "NO-FILL" logic can be

re-used.

My question is why do we have both "IgnoreBuffers"

and "BufferNoFill" in the code ?

"BufferNoFill" approach seems to be much better in my

opinion. However, it doesn't seems to be used in AE,

I see no client procedure setting this context

value...

Has "IgnoreBuffers" been replaced by "BufferNoFill",

but it hasn't been removed in the code ?

They have 2 different purposes.

'IgnoreBuffers' is used within the support code for the DAO to flag which buffers should not be used as part of the commitchanges routine, and as such can be used to control 'read-only' data, otherwise the code would attempt to save every buffer, even if you had simply included data for reference purposes in your dataset.

'BufferNoFill' is used as part of the fill process to determine if a buffer should indeed be filled with data or not.

HTH

Mike