Support Aggregation about camljs HOT 8 CLOSED

<View><ViewFields><FieldRef Name=\"cciContractStatus\" /><FieldRef Name=\"ID\" /></ViewFields><RowLimit Paged=\"TRUE\">1000</RowLimit><Aggregations Value=\"On\"><FieldRef Name=\"cciContractStatus\" Type=\"Count\" /></Aggregations><Query><Where><Eq><FieldRef Name='Status' /><Value Type='Text'>Expired</Value></Eq></Where><GroupBy Collapse=\"TRUE\" GroupLimit=\"100\"><FieldRef Name=\"cciContractStatus\"/></GroupBy></Query></View>

We use the aggregation along with the GroupBy quite often, but we had to resort to text manipulation.

from camljs.

@andrei-markeev Sorry for the super delayed response. Had some client critical stuff that came up. Was able to implement and things look great. Thanks you!!!

from camljs.

can you provide an example of aggregation that you would want to use?

from camljs.

This is not supported yet in CamlJs.
I will implement it (will take some time though, maybe few days).

Do you think syntax like below will do?

new CamlBuilder()
    .View(["cciContractStatus", "ID", CamlBuilder.Count("cciContractStatus")])
    .Query()
    .Where()
    .TextField("Status").EqualTo("Expired")
    .GroupBy({ collapse: true, groupLimit: 100 }, "cciContractStatus")
    .ToString()

from camljs.

Cool. Technically you could have multiple aggregations, I don't need it in my implementation right now, but I have tried it and it works. Secondly they have a number of operations: 'Sum' | 'Count' | 'Average' | 'Maximum' | 'Minimum' | 'Std Deviation' | 'Varience'. At least this is true in SharePoint. Maybe this:

new CamlBuilder()
    .View(["cciContractStatus", "ID", [CamlBuilder.Aggregation("cciContractStatus", "Count")]])
    .Query()
    .Where()
    .TextField("Status").EqualTo("Expired")
    .GroupBy({ collapse: true, groupLimit: 100 }, "cciContractStatus")
    .ToString()

Where the operation is a text string. You could enforce it to be the ones I named above I'm just not %100 sure that is all of them. So keeping it as a generic string with maybe the suggestion of one of those would be the safest. What do you think?

from camljs.

Technically you could have multiple aggregations

That's fine, you can pass all of them to View without need for additional array (trying to avoid nesting arrays, too many parenthesis, you know 😄). Also just to clarify, order is not important: I can parse it internally.

So could be like this:

.View([
    "ID",
    CamlBuilder.Count("cciContractStatus"),
    CamlBuilder.Sum("cciContractAmount"),
    "cciContractStatus" ])

You could enforce it to be the ones I named above I'm just not %100 sure that is all of them. So keeping it as a generic string with maybe the suggestion of one of those would be the safest.

The goal behind CamlJs is to have everything covered by intellisense, so that you can "explore" what you can do. Making it safe will never achieve that goal, I am afraid. If someone uses something outside of values you listed / can be found in docs, we just add them.

Also I was thinking that maybe instead of CamlBuilder.<operation> it is better to use an object of certain structure. This is covered by TypeScript pretty well, so e.g. you can have string | { sum: string } | { count: string } | ..., and in the code completion hint it will show all those options.

So in the end we can have something like this:

new CamlBuilder()
    .View([
        "cciContractStatus",
        { count: "cciContractStatus" }
    ])
    .Query()
    .Where().TextField("Status").EqualTo("Expired")
    .GroupBy({ collapse: true, groupLimit: 100 }, "cciContractStatus")
    .ToString()

Pretty much everyone knows SQL basics (unlike CAML), and in SQL if you want to have a group by, you write smth like this:

SELECT
    cciContractStatus,
    COUNT(cciContractStatus)
WHERE Status="Expired"
GROUP BY cciContractStatus

And now this is very similar to what we're getting, so I think the CamlJs version should feel good for most people!

from camljs.

Sounds great! Thanks for looking at this!

from camljs.

This is now implemented in Release 2.10.0, with one remark:

Turned out, current GroupBy definition had the following signature

        /** Adds GroupBy clause to the query.
            @param collapse If true, only information about the groups is retrieved, otherwise items are also retrieved. */
        GroupBy(fieldInternalName: any, collapse?: boolean): IGroupedQuery;

So instead of syntax proposed above with options as first parameter, we will have to live with passing groupLimit as third parameter. So like this:

        /** Adds GroupBy clause to the query.
            @param collapse If true, only information about the groups is retrieved, otherwise items are also retrieved.
            @param groupLimit Return only first N groups */
        GroupBy(fieldInternalName: any, collapse?: boolean, groupLimit?: number): IGroupedQuery;

I am not fully satisfied with this as obviously it doesn't support adding second Group By field.
So it might be there will be a follow-up minor release soon to address this issue.

I also started working on camljs-console update, because currently in live preview it uses getItems endpoint and passing aggregations there doesn't have any effect. Planning to switch over to renderListData.

Lastly, as always with new releases, updating DefinitelyTyped definitions might take couple of days. Npm and Nuget available right away.

Let me know if you notice any issues with the update!

from camljs.