-
Notifications
You must be signed in to change notification settings - Fork 596
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
Returning key identifier as part of data returned by query #594
Comments
Some related issues:
I think #574 would solve your issue. Regarding |
Thanks @jgeewax! My specific issue refers to retrieving entities. I actually think getting the This could be resolved by automatically populating the |
Gotcha, @byrneciaran Our worry (outlined in #508) is that |
Co-authored-by: release-please[bot] <55107282+release-please[bot]@users.noreply.github.com>
…andwritten libraries (#594) - [ ] Regenerate this pull request now. PiperOrigin-RevId: 429395631 Source-Link: googleapis/googleapis@84594b3 Source-Link: googleapis/googleapis-gen@ed74f97 Copy-Tag: eyJwIjoiLmdpdGh1Yi8uT3dsQm90LnlhbWwiLCJoIjoiZWQ3NGY5NzBmZDgyOTE0ODc0ZTZiMjdiMDQ3NjNjZmE2NmJhZmU5YiJ9
I use the key identifier extensively throughout my app as my "id". The namespace and kind doesn't change. Is it possible to return the key identifier inline with the data returned from queries or should I just include the identifier as a property on the entity ?
For example, if you look at this simple example of an entity returned by a query:
What I would like is for my data object to look like:
At the moment to include the key identifier with my data object I need to do something like:
NOTE - I use pop() here since it's in the examples but I think it's a bad idea. Poping the identifier removes it from the path array. If I go on to reuse the key, it's incomplete (e.g. if I did a get and update). I think entity.key.path[entity.key.path.length - 1] is a better idea.
Anyway, if I am returning thousands of entities I can write (using async.js) something like:
The problem I have is that (1) this is quite cumbersome (2) I haven't benchmarked but I'm sure there is a performance hit.
Is there a better way to do this ?
The text was updated successfully, but these errors were encountered: