FWD » Core Development » Database

Paraphrased from #2068:

Looks like P2J doesn't like the FIELDS clause, because with it, the fields get emitted as parameters to the *Query clause:

find first pers-addr.
for each person fields (emp-num first-name)
   where person.emp-num = pers-addr.emp-num:      
end.

converted as:

query1 = new AdaptiveQuery(person, "person.empNum = ?", null, "person.siteId asc, person.empNum asc", person.getEmpNum(), person.getFirstName(), new Object[]
{
   persAddr.getEmpNum()
});

We need to convert this. Ideally, I would like to see these emitted to a separate method call after the query is constructed, something like:

query1 = new AdaptiveQuery(person, ...);
query1.include("empNum", "firstName");

or, if using the EXCEPT option instead of FIELDS:

query1 = new AdaptiveQuery(person, ...);
query1.exclude("empNum", "firstName");

For a multi-buffer query (e.g., CompoundQuery), these calls would need to come after each query component is added, or be qualified by the buffer name.

The use cases we must support:

FOR EACH table1 FIELDS (field-1, field-2, ..., field-n)...

FOR FIRST table1 FIELDS (field-1, field-2, ..., field-n)...

FOR FIRST table1 FIELDS (field-1, field-2, ..., field-n)...,
    FIRST table2 FIELDS (field-1, field-2, ..., field-n)...

FOR EACH table1 FIELDS (field-1, field-2, ..., field-n)...,
    FIRST table2 FIELDS (field-1, field-2, ..., field-n)...

BTW, since multi-table queries also implement P2JQuery indirectly, they should throw UnsupportedOperationException for the include/exclude methods with an error message like, "Field list must be defined for an individual query component".

Also, we don't need runtime support for this feature yet, other than possibly storing the list of fields in an instance variable.

It is possible to reference an element of an extent field. The progress documentation says that "If field is an array reference, the whole array is retrieved even if only one element is specified.", so it is safe to drop the index and leave only the extent field name. Documentation doesn't say anything on how it works in the EXCEPT case, but

DISPLAY tt EXCEPT f3[2] WITH FRAME f1.

Stanislav Lomany wrote:

Do I need to ensure that there are no duplicates in the converted list (e.g. if we are converting EXCEPT(f3[1] f3[2]))?

Yes, please do, it will keep the converted code neater in this case.

Stanislav: if it doesn't take you long to build some rules which just drop/hide the FIELDS/EXCEPT nodes (so they will not be emitted), please make this change and send me an update (today would be best). I just want to put it through server folder conversion, to expose any other hidden compile errors.

OK

Removes FIELDS/EXCEPT nodes.

Thanks, I'm starting server folder conversion, hope nothing new will appear.

Unless someone has objections, for multi-component queries, I'll make include/exclude methods of the parent query:

query0 = new PresortQuery();
query0.enableBreakGroups();
query0.setNonScrolling();
query0.addComponent(tt, ((String) null));
query0.addComponent(tt2, ((String) null));
query0.addSortCriterion(byExpr0);

query0.include(tt, "f1", "f2");

OK, but please emit this method immediately after the associated addComponent call.

query0.include(tt, "f1", "f2");

Are you proposing to change the API to require a Buffer reference as the first parameter? Is this necessary?

For a multi-table query the buffer should be specified, but as an option we can have qualified field names:

query0.include("tt.f1", "tt.f2");

Stanislav Lomany wrote:

For a multi-table query the buffer should be specified, but as an option we can have qualified field names:
[...]

I don't want to parse qualified field names. If it's easier to specify the buffer, then so be it, but if the include/exclude method is specified immediately after the associated addComponent call, the context is enough for us to know with which buffer the fields are associated (i.e., the last one added). I don't think 2 versions of each include/exclude API are really necessary. If you want to specify the buffer, then do it consistently for single-buffer queries as well. Otherwise, I don't think it's necessary to specify the buffer. Am I missing a use case that this reasoning doesn't support?

So if the full list of options is:
1. Add the list of fields to query c'tor / addComponent
2. include(String ...) - should be called immediately after addComponent
3. include(DMO, String ...)

then me personally prefer the 3rd option: for the 1st case we already have a lot of parameters specified in c'tor / addComponent; for the 2nd case I don't like very much the idea of making calls order-dependent.

I guess there's one more option; chain the call, as in:

query0.addComponent(buffer, ...).include("f1", "f2", ...);

or

new AdaptiveQuery(buffer, ...).include("f1", "f2", ...);

In this case, addComponent will have to return Joinable or P2JQuery.

I was proposing option 2, but I can live with option 3. I still think the include/exclude call should directly follow the associated addComponent call. I think it is easier to understand this way.

Go with your favorite approach.

I still think the include/exclude call should directly follow the associated addComponent call. I think it is easier to understand this way.

For converted code - I agree, but I'm just afraid that someone who is writing code by hands may mess up with the order.

The update looks good to me. I am running conversion regression testing on it now.

The current fix doesn't work for all cases, e.g.:
1. REPEAT PRESELECT.
2. DEFINE QUERY.
Note that FIELDS/EXCEPT is specified for DEFINE QUERY rather than OPEN QUERY, so converted code should probably look like this:

TempRecord1.Buf tt = TemporaryBuffer.define(TempRecord1.Buf.class, "tt", false);

final QueryWrapper query0 = new QueryWrapper(false);

public void execute()
{
   externalProcedure(new Block()
   {
      public void init()
      {
         query0.include(tt, "f1");
      }