Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test: Restrict types inside the save function #1264

Merged
merged 12 commits into from
Aug 28, 2024

Conversation

danieljbruce
Copy link
Contributor

@danieljbruce danieljbruce commented Aug 16, 2024

Summary

To solve the problem described in go/excludefromindexes-nested-fields it is important to explore and document what kind of data can be passed into the save function. This PR defines interfaces and further restricts non-user facing variable types in the save source code so that the compiler will tell us when the source code is wrong. Right now, the first argument of save is of type Entities which is an alias for any.

Note: This PR doesn't change how the source code functions at all.

Changes

  • Two tests are added that demonstrate that when array data is passed into save that the elements of that array must contain valid name and value properties or else an error will be thrown.
  • In alignment with what is shown in the tests, a SaveArrayData interface is defined so that the compiler forces array data to match a type internally that won't throw an error.
  • An interface SaveNonArrayData is defined for valid input data that is not provided in array form
  • With SaveArrayData and SaveNonArrayData interfaces acting as building blocks, a hierarchy of other interfaces are defined that eventually define the SaveEntity interface which is now used in the save function to better restrict the data types that can be used within that function.
  • In PrepareEntityObjectResponse the data types for key and data are wrong, google.datastore.v1.Key and google.datastore.v1.Entity are references to functions and key and data properties do not store functions.

Next steps

It would be useful to further restrict the types within the save function to make it easier to work with the complex data structures that are involved with the problem from go/excludefromindexes-nested-fields

We need help from the compiler so these interfaces will be useful for determining the shape of the data.
The interfaces should match the actual data types that get passed in.
@product-auto-label product-auto-label bot added size: s Pull request size is small. api: datastore Issues related to the googleapis/nodejs-datastore API. labels Aug 16, 2024
@product-auto-label product-auto-label bot added size: m Pull request size is medium. and removed size: s Pull request size is small. labels Aug 16, 2024
save doesn’t encode strings or ints or any values that don’t have keys properly so we should restrict the interface to what it does include.
@danieljbruce danieljbruce changed the title test: TODO test: Restrict types inside the save function Aug 16, 2024
@danieljbruce danieljbruce changed the base branch from main to 1242-to-main-2 August 16, 2024 20:51
@danieljbruce danieljbruce marked this pull request as ready for review August 16, 2024 20:52
@danieljbruce danieljbruce requested review from a team as code owners August 16, 2024 20:52
Copy link

@daniel-sanche daniel-sanche left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Entity data passed into save in an array form will be of type SaveArrayData
so will have name and value defined because they are needed in these places:
https://github.com/googleapis/nodejs-datastore/blob/bf3dafd8267c447a52f7764505042a60b1a9fd28/src/index.ts#L1152
https://github.com/googleapis/nodejs-datastore/blob/bf3dafd8267c447a52f7764505042a60b1a9fd28/src/index.ts#L1134

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These links seem likely to become irrelevant over time. Can the prurpose of this interface be described in a more general way?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. I just updated it. The links are permalinks, but I did just update the description inline.

An Entity passed into save will include a Key object contained either inside
a `key` property or inside a property indexed by the Key Symbol. If it is
the former then it will be of type SaveEntityWithoutKeySymbol.
*/

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This part is a little unclear to me, I don't understand what the Key Symbol is or how it's used. Maybe that's just because I'm not familiar with the repo though

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

export const KEY_SYMBOL: unique symbol = Symbol('KEY');
is the key symbol. Let me know if you want to reword.

@danieljbruce danieljbruce merged commit b77406b into 1242-to-main-2 Aug 28, 2024
13 checks passed
@danieljbruce danieljbruce deleted the 1242-consider-interface-change branch August 28, 2024 14:24
danieljbruce added a commit that referenced this pull request Aug 28, 2024
… of nested fields (#1266)

* test: Restrict types inside the save function (#1264)

* Add interfaces that restrict values passed to save

* Add interfaces for save

We need help from the compiler so these interfaces will be useful for determining the shape of the data.

* Modify current interfaces to make a closer match

The interfaces should match the actual data types that get passed in.

* key and data in PrepareEntityObjectResponse option

These properties are actually optional

* Document all the interfaces added for the save fn

* Add two tests showing name/value should be provide

* Make the SaveNonArrayData more specific.

save doesn’t encode strings or ints or any values that don’t have keys properly so we should restrict the interface to what it does include.

* Add header

* Test should be more flexible

* Add a class for elements with ToString

* Define the toString class inline

* Eliminate links to points in code

* test: Add tests that describe how save should encode excludeFromIndexes for a complex case (#1263)

* Write a sample test for what save output should be

* Add a test for a bunch of complex excludeFromIndex

* Change the replace function so it works everywhere

* Modify the expected value

Make it contain longStringArray

* Correct the test for evaluating arrays

* Break up the entityToEntityProto into separate par

* Fix the tests to work with new addExcludeFromIndex

* Revert "Break up the entityToEntityProto into separate par"

This reverts commit 60dabd7.

* Revert "Fix the tests to work with new addExcludeFromIndex"

This reverts commit ba4e82b.

* Remove source code changes

* Skip the test that looks at arrays

* Remove some of the wildcard indexes

This is in excludeFromIndexes - replace them with literals.

* Remove another boolean value from excludeFromIndex

* Eliminate duplicate expectedMutations

* Eliminate duplicate runTest function

* Begin to set up the async tests

* Pack all tests into the async framework

* Delete tests addressed by async

* Get rid of test functions and inline everything

* Add comment

* Add comments describing each test case

* Remove only

* Add another test looks at name/value not in array

* Add a test for excludeLarge properties and name/va

* Fix the test so that the array case matches

Matches the single case

* should pass the right properties for an array

* Rename the test

* Change name to entityName

* Add two tests that capture the array encoding

encoding problem

* Change expected output of arrays

* Remove only

* Add 2 more tests to ensure behaviour is preserved

* Correct test - it should apply excludeFromIndexes

* Update the test for the nested value

* fix: Handle excludeLarge properties for arrays properly (#1265)

* Write a sample test for what save output should be

* Add a test for a bunch of complex excludeFromIndex

* Change the replace function so it works everywhere

* Modify the expected value

Make it contain longStringArray

* Correct the test for evaluating arrays

* Break up the entityToEntityProto into separate par

* Fix the tests to work with new addExcludeFromIndex

* Break up the entityToEntityProto into separate par

* Fix the tests to work with new addExcludeFromIndex

* Revert "Break up the entityToEntityProto into separate par"

This reverts commit 60dabd7.

* Revert "Fix the tests to work with new addExcludeFromIndex"

This reverts commit ba4e82b.

* Remove source code changes

* Skip the test that looks at arrays

* Remove some of the wildcard indexes

This is in excludeFromIndexes - replace them with literals.

* Remove another boolean value from excludeFromIndex

* Eliminate duplicate expectedMutations

* Eliminate duplicate runTest function

* Begin to set up the async tests

* Pack all tests into the async framework

* Delete tests addressed by async

* Get rid of test functions and inline everything

* Add comment

* Add comments describing each test case

* Remove only

* Add another test looks at name/value not in array

* Add a test for excludeLarge properties and name/va

* Fix the test so that the array case matches

Matches the single case

* should pass the right properties for an array

* Rename the test

* Change name to entityName

* Add two tests that capture the array encoding

encoding problem

* Change expected output of arrays

* Remove only

* Add 2 more tests to ensure behaviour is preserved

* Make argument more specific for excludeFromIndexes

* Use excludeLargeProperties for array/non-array cas

* Fix the test to include entity proto

* Correct mistakes in initial implementation

* Don’t skip any of the tests

* Remove only

* Add check for excludeLargeProperties

* Remove TODO

* 🦉 Updates from OwlBot post-processor

See https://github.com/googleapis/repo-automation-bots/blob/main/packages/owl-bot/README.md

* 🦉 Updates from OwlBot post-processor

See https://github.com/googleapis/repo-automation-bots/blob/main/packages/owl-bot/README.md

---------

Co-authored-by: Owl Bot <gcf-owl-bot[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: datastore Issues related to the googleapis/nodejs-datastore API. size: m Pull request size is medium.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants