FWD » Core Development » Database

Greg,

There are only 4 uses of this statement across both projects (all in the server project), and they are all of the simplest possible form: INSERT <table> (i.e., no options). I would propose that our initial implementation is simply to convert:

INSERT <table>.

to

CREATE <table>.
UPDATE <table>.

during annotations (or perhaps even earlier...fixups?) -- provided testing in the 4GL shows these are equivalent -- and let the normal conversion run its course.

We can create a separate issue to make a prettier and/or more compact conversion and to support the various options of INSERT later if necessary. In fact, as part of that, we could recognize the CREATE, UPDATE sequence and refactor that into the better conversion if the use of options (or lack thereof) allow it.

Thoughts?

I first tested if the sequence of CREATE/UPDATE has the same effect like INSERT. My fear was that if user skips the UPDATE screen a new record would be inserted into table, which should not happen in the case of INSERT as this would be an atomic change to table.
First, the real thing, on windev01. A simple program like

CREATE Customer.
UPDATE Customer.

The implementation. In post_parse_fixups.xml, when walking on a STATEMENT which has only one child of type INSERT, it is replaced by two duplicates, but having their only child changed to CREATE / UPDATE. This way, the newly added nodes keep lexer information about line/col of the original INSERT statement node.

I uploaded the update which contains a testcase, too, please review.

Code looks good, but I should not have suggested that this go into post-parse fixups. This is too early, and it will result in the analysis reports (which run after post-parse fixups) being misleading, since they will not show any INSERT statement use.

It is better placed in the annotations phase. Specifically, the insert expansion rule must take place before annotations/record_field_expansion.rules. Please create annotations/insert_statement_expansion.rules and call it from within annotations.xml, right at the beginning of the database support section, just before record_field_expansion.

Replacement of INSERT by CREATE+UPDATE moved to new ruleset file. The intermediary files generated differ just by peerIds.