Subqueries do not compose

[ChuckJonas]

• Bug Request

I can't seem to get the subqueries to "compose". Tried different combinations of sObject and sObjectRelationshipName but nothing seems to work.

Description

        let x = {
            "fields": [],
            "sObject": "Account",
            "subqueries": [
              {
                "fields": [
                  {
                    "text": "Id"
                  },
                  {
                    "text": "Name"
                  }
                ],
                // "sObject": 'Contacts', //tried with different variations of these two params... nothing works:
                "sObjectRelationshipName": "Contacts",
                "subqueries": []
              }
            ]
        }
        let s = composeQuery(x);

AssertionError: expected 'SELECT FROM Account' to equal 'SELECT (SELECT Id, Name FROM Contacts) FROM Account'
+ expected - actual

  -SELECT  FROM Account
  +SELECT (SELECT Id, Name FROM Contacts) FROM Account

[ChuckJonas]

I was able to work around this by just pushing it to a new field like so:

let subqry = {
  "fields": [{
      "text": "Id"
  }, {
      "text": "Name"
  }],
  "sObject": "Contacts"
  "subqueries": []
}

let parent = {
  "fields": [{
      text: `(${compose(subqry)})`
  }],
  "sObject": "Account",
  "subqueries": []
}

Not ideal, but it works for now. I might take a stab at trying to fix it once I get the query generator I'm working on wrapped up)

[paustint]

@ChuckJonas - the way that subqueries are setup is the in the list of fields there is a reference to the subquery child relationship API name, then the actual query should be in the subquery array.

Again, I am open to feedback on this structure. Maybe it would make more sense to have the subquery directly in the field instead of stored as a separate array?

So in your example above it should be structured like the example below:

let x = {
    "fields": [
      {
        "text": "Id"
      },
      {
        "subqueryObjName": "Contacts"
      },
    ],
    "sObject": "Account",
    "subqueries": [
      {
        "fields": [
          {
            "text": "Id"
          },
          {
            "text": "Name"
          }
        ],
        "sObjectRelationshipName": "Contacts",
        "subqueries": []
      }
    ]
}
let s = composeQuery(x);

Here is a unit test you can reference:

  {
    testCase: 13,
    soql: 'SELECT Name, (SELECT LastName FROM Contacts) FROM Account',
    output: {
      fields: [
        {
          text: 'Name',
        },
        {
          subqueryObjName: 'Contacts',
        },
      ],
      subqueries: [
        {
          fields: [
            {
              text: 'LastName',
            },
          ],
          subqueries: [],
          sObjectRelationshipName: 'Contacts',
        },
      ],
      sObject: 'Account',
    },
  },

[ChuckJonas]

ahh interesting.... The syntax is a little confusing, but I can see why you might want to keep the subqueries out of the select. Your current setup has the added benefits of preventing Cannot follow the same aggregate relationship twice (maybe?).

I would say do whatever fits your needs best. I'm using this library in a typesafe query generator of an typescript ORM I wrote. Because it often is run in the browser, I think I may end up needing to write my own code to compose the queries (simply due to the added overhead of antlr).

[paustint]

@ChuckJonas - Thanks for the feedback, I will give it some thought and will probably keep it as is for now.

Also, as far as bundle size, I am planning to use it in an Angular application with lazy loading and here is what I found about the bundle size. I think this is the non-gzipped size - but it appears to add just under 500k.

[ChuckJonas]

ya, that seems to match up what bundlephobia show. Also, looks like it's "tree shakable", so if your using it with webpack, and not using all the functionality, it will probably be even smaller.

I'd really like to include my query generator directly in ts-force (instead having ts-force-qry as a peer package), but it would increase the overall size by ~ 5x.

Not sure it REALLY matters in this day in age. Especially since I'm typically also using a component library like antd which is 1.8mB

[paustint]

@ChuckJonas - check out the recent changes (on master, released as a beta). There updates in the examples in the README for composing queries with the new structure.

Also, I have added comments for various fields on the README (and in the soql models TS file) denoting which fields are not expected to be populated if you are composing a query.

Let me know if you have any questions or have suggestions on doc updates or code/type changes after you spend some time using it.