Query data

RE: Query data

Mike Schmitt — Sat, 18 May 2024 14:30:25 GMT

without seeing what exactly you're trying and what exactly your query output / error is, it's hard to say, but i'm guessing you're mixing up indexing (in terms of array position) with trying to fetch the record type property (which needs to be fetched not with a dot property but either with square brackets that contain the record property reference, or in the "property()" function where the record type property reference is passed instead of the plaintext field name).

RE: Query data

Rahul009 — Sat, 18 May 2024 11:51:32 GMT

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.

RE: Query data

Peter Lewis — Fri, 17 May 2024 13:03:20 GMT

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.

RE: Query data

Rahul009 — Thu, 16 May 2024 17:22:33 GMT

Yes Mike Schmitt , that's right.

RE: Query data

Konduru Chaitanya — Thu, 16 May 2024 12:57:00 GMT

Okay, got it!

RE: Query data

Mike Schmitt — Thu, 16 May 2024 12:55:58 GMT

[quote userid="140649" url="~/discussions/f/new-to-appian/35003/query-data/135440"]That is how it works. I still do not understand your question [/quote]

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.

RE: Query data

Konduru Chaitanya — Thu, 16 May 2024 12:53:28 GMT

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.

RE: Query data

Mike Schmitt — Thu, 16 May 2024 12:31:21 GMT

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.

RE: Query data

Rahul009 — Thu, 16 May 2024 12:16:01 GMT

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", {})
  )
)

RE: Query data

Mike Schmitt — Thu, 16 May 2024 12:15:50 GMT

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.

RE: Query data

Konduru Chaitanya — Thu, 16 May 2024 11:54:19 GMT

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