Query data

Please share the code snippet of both your query rule and the interface.

Queried data (of any type, be it record type or entity) is automatically treated as a list (whether single, empty, or list) until you specify otherwise.

A common way of forcing the output to appear as single is to use the square bracket indexing to specify the first result (which is necessary even if there's only one) - like [1] after ".data" (being the result of your query).  One issue this creates is it'll break (error) if the query actually returns empty - so instead we use index() for what it's intended for, i.e. to grab the first index (if any) and specify a default value otherwise...

index(local!myQueryResult.data, 1, {})  (note: you should replace "{}" here with "null()" to force the output to show up as simply blank instead of an empty list, if desired)

and, as always, to avoid confusion and increase code readability, i strongly suggest that you use property() to retrieve a specific field instead of index(), since "index" implies a position in an array, and "property" implies a particular data property.

As Konduru mentioned already, sharing a code snippet and/or result screenshots would help us specify what you'd need to do in your particular case.

Below query I am using for diffrent record types

a!localVariables(
  local!data: a!queryRecordType(
    recordType: "recordType!HM Patient",
    fields: ri!selectionField,
    filters: a!queryLogicalExpression(
      logicalExpressions: ri!logicalExpression,
      operator: "AND",
      filters: {
        a!queryFilter(
          field: "recordType!HM Patient.fields.patientIdPk_int",
          operator: "=",
          value: ri!patientIdPk_int
        ),
        a!queryFilter(
          field: "recordType!HM Patient.fields.genderId_int",
          operator: "=",
          value: ri!genderId_int
        ),
        ri!filters
      },
      ignoreFiltersWithEmptyValues: true
    ),
    pagingInfo: a!defaultValue(
      value: ri!pagingInfo,
      default: a!pagingInfo(
        startIndex: 1,
        batchSize: 50,
        sort: {
          a!sortInfo(
            field: "recordType!HM Patient.fields.patientIdPk_int",
            ascending: false()
          )
        }
      )
    ),
    fetchTotalCount: or(ri!fetchTotalCount_bool)
  ),
  if(
    or(ri!returnDataSubset_bool),
    local!data,
    index(local!data, "data", {})
  )
)

let me know if my earlier reply (below) makes any sense.  it looks like this is a standard use case, though it'll depend on exactly what the context is in which you want to force the returned value to not snow up as a list.

Are you trying to say, when you are passing certain fields into the ri!selectionField you get some list and when you don't pass you are still getting the list?

If so, That is how it works. I still do not understand your question to be frank.

Konduru Chaitanya said:

That is how it works. I still do not understand your question

He's saying (unless i'm sorely mistaken) that there are some conditions in which a query will return one entry and some in which it returns zero entries, and is confused that the output is still "list type".  Hence my explanation below of how to manually handle this when necessary.

Okay, got it!

Yes Mike Schmitt , that's right.

I agree with what others have said about why this happens, but in general I would suggest keeping the return type as a list if it can return a variable number of results. In some cases it can actually make it harder to manage if your return type is sometimes a list or sometimes a single item. However, if it's always a list (even if it's a list of one or zero), then it's easier to troubleshoot issues and design in a way that lists are supported.

The case to me where it does make sense to cast it to a single item (like Mike suggested) is when you know it will always return a single item (or null). For example, if you have a query that filters by the primary key, it's guaranteed to only return a single item, so you might as well cast the type to a single item as well.

Hi Mike Schmitt, As per above, I am not sure if .data in recordtype will be supported. .data gives error "can only be indexed using square brackets" when there is one record in output. And if indexed using square brackets then it gives error "invalid index" when output is null.