Why isn't this on Notion-Version 2022-06-28?

[JamesNZL]

Why is this repository still on v1.0.4 of @makenotion/notion-sdk-js?

[JamesNZL]

Working branch for v2.0.0 commits is #43.

[JamesNZL]

Notion-Version 2022-06-28

As per the Notion-Version 2022-06-28 changelog:

Page properties must be retrieved using the page properties endpoint.

Thus moving forward, all property value retrieval must happen through the retrieve a page property item endpoint.

What does this mean?

This results in a significant performance degradation when querying the pages (with the properties of those pages) belonging to a database.

To illustrate this with an example:

Let's say we're wanting to retrieve all the pages contained within database x. For each of those pages, we want to read the value of property y, which we can use to 'do a thing'.

Before Notion-Version 2022-06-28

Previously, the page object returned from page endpoints, as well as the query database and search endpoint, returned a properties field that contained all the page’s properties along with its value.

This can be performed with a single (paginated) POST request to the Query a database endpoint, which returns a list of page objects belonging to database x.
This list is fully qualified with the page properties, including all the values of property y.

This is an O(1) (constant time) process for any arbitrary database with an arbitrary n pages, ignoring any additional requests that may be necessary due to pagination.

After Notion-Version 2022-06-28

With version 2022-06-28, the type and property value from page objects are removed. Thus moving forward, all property value retrieval must happen through the retrieve a page property item endpoint.

This now requires:

1. A single (paginated) POST request to the Query a database endpoint, which returns a list of page objects belonging to database x.

   This is now without the page property values, only the ids of the properties belonging to each page.

2. An individual GET request for each page to the Retrieve a page property item endpoint, which returns the desired property value of y.

This is now an O(n) process for a database with n pages.

For slow internet connections, or databases with many pages (as is likely to be the case for this extension), this will be a big problem.

Why is this relevant?

When the Export to Notion button is clicked, this extension ensures that it only imports new assignments.

It only imports Canvas assignments that do not already exist in the configured database.

This is done by:

1. Querying the configured database,
2. Getting a list of the Canvas assignment URLs (eg https://canvas.auckland.ac.nz/courses/72763/assignments/271174) that already belong to a Notion task page, and
3. Importing only the saved assignments whose URLs are not present in the list.

• Before 2022-06-28, this is one (paginated) API call.
• As of 2022-06-28, this is one (paginated) API call, plus an additional request for every page in the database.

What can be done?

• I am already applying a filter condition to the Query a database endpoint to only query for Canvas assignment pages (using the Category select property).

• I could (and will, on this branch) add an additional filter to only query for pages with a non-empty notion.propertyNames.URL property.

However, this does not fix the necessary O(n) requests for the queried pages, it just minimises the value of n.

• I could set notionVersion in the Client constructor to be < 2022-06-28.

However, the type declarations in v2.0.0 will still be those of 2022-06-28.
As this is a TypeScript project, this means that I will either need to deal with compilation errors, no-check directives, unsafe type assertions, or other undesirable work-arounds.

• Use Promise.all([]) to make 'parallel' requests.

Although this would indeed 'fix' the O(n) problem, this still results in an unnecessarily high number of network requests, and risks being rate-limited.

For these reasons, I do not intend on updating to v2.0.0.

This may change if there are future changes that necessitate it, or changes that reduce this performance degradation.

[JamesNZL]

With #97, the reasons detailed in the previously-accepted answer are made moot, as the API once again returns page property values in the Query a database endpoint.