FWD » Core Development » Database

We need to add support for the following (according to gap marking):

• BUFFER handle usage
  • PRIMARY attribute (marked runtime stubs)
  • BUFFER-VALIDATE() method (marked none/untested - seems to be mismarked, support looks to be full/full)
• BUFFER-FIELD handle usage
  • KEY attribute (marked runtime stubs)
  • PRIMARY attribute (marked none/none)
  • DECIMALS attribute (marked runtime stubs)
  • KEY attribute (marked runtimestubs)

When implementing the runtime support for buffer-handle:PRIMARY, consider supporting temp-table-handle:PRIMARY if it can be implemented with little effort.

Ovidiu Maxiniuc wrote:

I have implementation of some of the above attributes/methods as a pending changeset for 6129a.

What is blocking your changes from being committed?

What is left after that? I was going to assign this to Stanislav, unless you are nearly finished. I'm assuming not, since you marked it 30% done.

Eric Faulhaber wrote:

What is blocking your changes from being committed?

I am waiting for Constantin's green light #6502-9 / 10 / 14.

What is left after that? I was going to assign this to Stanislav, unless you are nearly finished. I'm assuming not, since you marked it 30% done.

• BUFFER-FIELD:KEY: 100% conversion + runtime;
• BUFFER & TEMP-TABLE:PRIMARY: 100% conversion + runtime getter (missing setter support). The TEMP-TABLE delegates the calls to default buffer, in all cases. There is no such attribute for BUFFER-FIELD;
• BUFFER:BUFFER-VALIDATE() method is, indeed, 100% supported conversion + runtime. The gap must be updated;
• BUFFER-FIELD:DECIMALS also 100% supported conversion + runtime. I guess the gap must be updated;
• I guess the second KEY is in fact, KEYS. This is already implemented for BUFFER and DATA-SOURCE.

Thanks, Ovidiu. Please update the incorrect gap markings as part of your commit.

Constantin, it's been a few weeks with #6502. Have you had a chance to do the testing you wanted to do? I'd like to get Ovidiu's changes into 6129a, if you think it's ok.

Ovidiu, please upload #6502 and #6450 as a patch and I'll test conversion on my side.

Sorry, I thought I already mentioned this in #6502.

Ovidiu, I see there was a review cycle in #6502 and a commit of your changes to 6129a. Given that, is there anything left to do here, or can this be considered complete? What testing has been done? It looks like the gap markings mentioned in #6450-6 have been corrected in that commit, is that right? Thanks.

I did not work with 6129a lately so I had to update the branch and review those changes. Constantin did the rebase against 3821c and, beside increasing the revision numbers, bzr got confused and reported a lot of conflicts.

Eric Faulhaber wrote:

Ovidiu, I see there was a review cycle in #6502 and a commit of your changes to 6129a. Given that, is there anything left to do here, or can this be considered complete?

Yes, I think the answer is positive.

What testing has been done?

I used my isolated testcases based on reference information. However, testing in real-live projects have not been done since these methods/attributes are implemented here for the first time. With the exception of BUFFER-VALIDATE().

It looks like the gap markings mentioned in #6450-6 have been corrected in that commit, is that right? Thanks.

It seems that the gap for BUFFER-VALIDATE() was not updated. I will do that in 3821c and, with next rebase, 6129a will inherit it naturally.

Can this be closed?

Yes, I think so.
Note that, unlike #6444 (where the changes were committed to 3821c), this task uses 6129a/b.