-
Notifications
You must be signed in to change notification settings - Fork 206
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
TypeScript streamFetchByKey should support multiple {template, key} pairs per request #7034
Labels
component/json-api
HTTP JSON API
team/ledger-clients
Related to the Ledger Clients team's components.
Milestone
Comments
garyverhaegen-da
added a commit
that referenced
this issue
Aug 7, 2020
This is an attempt to address #7034 & #7036. I'd like to gather feedback before moving further, though, because while I believe (based on limited problem domain knowledge) that this is the rigth way to address them, strictly speaking this does not fulfill their stated acceptance criteria. CHANGELOG_BEGIN deprecation warning & upgrade instructions to be fleshed out CHANGELOG_END
garyverhaegen-da
added a commit
that referenced
this issue
Aug 7, 2020
This is an attempt to address #7034 & #7036. I'd like to gather feedback before moving further, though, because while I believe (based on limited problem domain knowledge) that this is the rigth way to address them, strictly speaking this does not fulfill their stated acceptance criteria. In particular, I have chosen to keep limiting both scopes to a single template ID. Ignoring the fact that I'm having trouble reasoning about the type of the resulting stream if we accept arbitrary lists of template IDs in these calls, I'm also questioning whether we want to encourage our users to build their applications on top of such dynamically heterogeneous lists. CHANGELOG_BEGIN deprecation warning & upgrade instructions to be fleshed out CHANGELOG_END
garyverhaegen-da
added a commit
that referenced
this issue
Aug 10, 2020
This is an attempt to address #7034 & #7036. I'd like to gather feedback before moving further, though, because while I believe (based on limited problem domain knowledge) that this is the rigth way to address them, strictly speaking this does not fulfill their stated acceptance criteria. In particular, I have chosen to keep limiting both scopes to a single template ID. Ignoring the fact that I'm having trouble reasoning about the type of the resulting stream if we accept arbitrary lists of template IDs in these calls, I'm also questioning whether we want to encourage our users to build their applications on top of such dynamically heterogeneous lists. CHANGELOG_BEGIN deprecation warning & upgrade instructions to be fleshed out CHANGELOG_END
garyverhaegen-da
added a commit
that referenced
this issue
Aug 11, 2020
This is an attempt to address #7034 & #7036. I'd like to gather feedback before moving further, though, because while I believe (based on limited problem domain knowledge) that this is the rigth way to address them, strictly speaking this does not fulfill their stated acceptance criteria. In particular, I have chosen to keep limiting both scopes to a single template ID. Ignoring the fact that I'm having trouble reasoning about the type of the resulting stream if we accept arbitrary lists of template IDs in these calls, I'm also questioning whether we want to encourage our users to build their applications on top of such dynamically heterogeneous lists. CHANGELOG_BEGIN deprecation warning & upgrade instructions to be fleshed out CHANGELOG_END
garyverhaegen-da
added a commit
that referenced
this issue
Aug 11, 2020
This is an attempt to address #7034 & #7036. Strictly speaking, this does not match their acceptance criteria, as this only supports multiple queries, not mixed templates. This also results in a somewhat confusing API because we end up with overlapping functions: the new `streamQueries` can do everything that the existing `streamQuery` can do, and the new `streamFetchByKeys` can do everything that the existing `streamFetchByKey` can do, but we have decided to keep the existing ones for now, to avoid breaking backwards compatibility. CHANGELOG_BEGIN - [JavaScript Client Libraries] Two new methods have been added to `daml-ledger`: `streamQueries` and `streamFetchByKeys`. They are similar to the existing singular versions, except they can take multiple queries and multiple keys, respectively, and return a union of what the corresponding individual queries/keys would have. CHANGELOG_END
garyverhaegen-da
added a commit
that referenced
this issue
Aug 11, 2020
This is an attempt to address #7034 & #7036. Strictly speaking, this does not match their acceptance criteria, as this only supports multiple queries, not mixed templates. This also results in a somewhat confusing API because we end up with overlapping functions: the new `streamQueries` can do everything that the existing `streamQuery` can do, and the new `streamFetchByKeys` can do everything that the existing `streamFetchByKey` can do, but we have decided to keep the existing ones for now, to avoid breaking backwards compatibility. CHANGELOG_BEGIN - [JavaScript Client Libraries] Two new methods have been added to `daml-ledger`: `streamQueries` and `streamFetchByKeys`. They are similar to the existing singular versions, except they can take multiple queries and multiple keys, respectively, and return a union of what the corresponding individual queries/keys would have. CHANGELOG_END
garyverhaegen-da
added a commit
that referenced
this issue
Aug 25, 2020
This is an attempt to address #7034 & #7036. Strictly speaking, this does not match their acceptance criteria, as this only supports multiple queries, not mixed templates. Because the two new functions can cover the exact same use cases (and more) as the existing `streamQuery` and `streamFetchByKey`, the latter are deprecated. The deprecation cycle I suggest is to deprecate them immediately by annotating them as such in the documentation (done on this PR). That's it. I do not think we ever need to actually remove them, nor to make them print annoying warnings or anything. There is nothing wrong with the functions as they stand, they just don't fit in the API anymore. We could, at some point, move them to a separate documentation page, or to the bototm of the existing one, but I feel even removing them from the documentation is unnecessary. CHANGELOG_BEGIN - [JavaScript Client Libraries] Two new methods have been added to `daml-ledger`: `streamQueries` and `streamFetchByKeys`. They are similar to the existing singular versions, except they can take multiple queries and multiple keys, respectively, and return a union of what the corresponding individual queries/keys would have. Because these new functions can do everything the existing ones can, we are deprecating the latter, though there is no plan to remove them. Upgrade path is straightforward: ``` streamQuery(t); => streamQueries(t, []); streamQuery(t, undefined); => streamQueries(t, []); streamQuery(t, q); => streamQueries(t, [q]); streamFetchByKey(t, k); => streamFetchByKey(t, [k]); ``` There is one caveat, though: `streamFetchByKeys` is a little bit less lenient in the format in which it expects the key. If your existing code was conforming to the generated TypeScript code we provide, everything should keep working, but if you were using plain JS or bypassing the TS type system, it is possible that you used to construct keys that will no longer be accepted. The new function requires all keys to be given in the _output_ format of the JSON API, which is a little bit more strict than the general JSON <-> LF conversion rules. CHANGELOG_END
garyverhaegen-da
added a commit
that referenced
this issue
Aug 25, 2020
This is an attempt to address #7034 & #7036. Strictly speaking, this does not match their acceptance criteria, as this only supports multiple queries, not mixed templates. Because the two new functions can cover the exact same use cases (and more) as the existing `streamQuery` and `streamFetchByKey`, the latter are deprecated. The deprecation cycle I suggest is to deprecate them immediately by annotating them as such in the documentation (done on this PR). That's it. I do not think we ever need to actually remove them, nor to make them print annoying warnings or anything. There is nothing wrong with the functions as they stand, they just don't fit in the API anymore. We could, at some point, move them to a separate documentation page, or to the boottm of the existing one, but I feel even removing them from the documentation is unnecessary. CHANGELOG_BEGIN - [JavaScript Client Libraries] Two new methods have been added to `daml-ledger`: `streamQueries` and `streamFetchByKeys`. They are similar to the existing singular versions, except they can take multiple queries and multiple keys, respectively, and return a union of what the corresponding individual queries/keys would have. Because these new functions can do everything the existing ones can, we are deprecating the latter, though there is no plan to remove them. Upgrade path is straightforward: ``` streamQuery(t); => streamQueries(t, []); streamQuery(t, undefined); => streamQueries(t, []); streamQuery(t, q); => streamQueries(t, [q]); streamFetchByKey(t, k); => streamFetchByKey(t, [k]); ``` There is one caveat, though: `streamFetchByKeys` is a little bit less lenient in the format in which it expects the key. If your existing code was conforming to the generated TypeScript code we provide, everything should keep working, but if you were using plain JS or bypassing the TS type system, it is possible that you used to construct keys that will no longer be accepted. The new function requires all keys to be given in the _output_ format of the JSON API, which is a little bit more strict than the general JSON <-> LF conversion rules. CHANGELOG_END
garyverhaegen-da
added a commit
that referenced
this issue
Aug 25, 2020
This is an attempt to address #7034 & #7036. Strictly speaking, this does not match their acceptance criteria, as this only supports multiple queries, not mixed templates. Because the two new functions can cover the exact same use cases (and more) as the existing `streamQuery` and `streamFetchByKey`, the latter are deprecated. The deprecation cycle I suggest is to deprecate them immediately by annotating them as such in the documentation (done on this PR). That's it. I do not think we ever need to actually remove them, nor to make them print annoying warnings or anything. There is nothing wrong with the functions as they stand, they just don't fit in the API anymore. We could, at some point, move them to a separate documentation page, or to the boottm of the existing one, but I feel even removing them from the documentation is unnecessary. CHANGELOG_BEGIN - [JavaScript Client Libraries] Two new methods have been added to `daml-ledger`: `streamQueries` and `streamFetchByKeys`. They are similar to the existing singular versions, except they can take multiple queries and multiple keys, respectively, and return a union of what the corresponding individual queries/keys would have. Because these new functions can do everything the existing ones can, we are deprecating the latter, though there is no plan to remove them. Upgrade path is straightforward: ``` streamQuery(t); => streamQueries(t, []); streamQuery(t, undefined); => streamQueries(t, []); streamQuery(t, q); => streamQueries(t, [q]); streamFetchByKey(t, k); => streamFetchByKey(t, [k]); ``` There is one caveat, though: `streamFetchByKeys` is a little bit less lenient in the format in which it expects the key. If your existing code was conforming to the generated TypeScript code we provide, everything should keep working, but if you were using plain JS or bypassing the TS type system, it is possible that you used to construct keys that will no longer be accepted. The new function requires all keys to be given in the _output_ format of the JSON API, which is a little bit more strict than the general JSON <-> LF conversion rules. CHANGELOG_END
garyverhaegen-da
added a commit
that referenced
this issue
Aug 25, 2020
This is an attempt to address #7034 & #7036. Strictly speaking, this does not match their acceptance criteria, as this only supports multiple queries, not mixed templates. Because the two new functions can cover the exact same use cases (and more) as the existing `streamQuery` and `streamFetchByKey`, the latter are deprecated. The deprecation cycle I suggest is to deprecate them immediately by annotating them as such in the documentation (done on this PR). That's it. I do not think we ever need to actually remove them, nor to make them print annoying warnings or anything. There is nothing wrong with the functions as they stand, they just don't fit in the API anymore. We could, at some point, move them to a separate documentation page, or to the boottm of the existing one, but I feel even removing them from the documentation is unnecessary. CHANGELOG_BEGIN - [JavaScript Client Libraries] Two new methods have been added to `daml-ledger`: `streamQueries` and `streamFetchByKeys`. They are similar to the existing singular versions, except they can take multiple queries and multiple keys, respectively, and return a union of what the corresponding individual queries/keys would have. Because these new functions can do everything the existing ones can, we are deprecating the latter, though there is no plan to remove them. Upgrade path is straightforward: ``` streamQuery(t); => streamQueries(t, []); streamQuery(t, undefined); => streamQueries(t, []); streamQuery(t, q); => streamQueries(t, [q]); streamFetchByKey(t, k); => streamFetchByKey(t, [k]); ``` There is one caveat, though: `streamFetchByKeys` is a little bit less lenient in the format in which it expects the key. If your existing code was conforming to the generated TypeScript code we provide, everything should keep working, but if you were using plain JS or bypassing the TS type system, it is possible that you used to construct keys that will no longer be accepted. The new function requires all keys to be given in the _output_ format of the JSON API, which is a little bit more strict than the general JSON <-> LF conversion rules. CHANGELOG_END
garyverhaegen-da
added a commit
that referenced
this issue
Sep 8, 2020
This is an attempt to address #7034 & #7036. Strictly speaking, this does not match their acceptance criteria, as this only supports multiple queries, not mixed templates. Because the two new functions can cover the exact same use cases (and more) as the existing `streamQuery` and `streamFetchByKey`, the latter are deprecated. The deprecation cycle I suggest is to deprecate them immediately by annotating them as such in the documentation (done on this PR). That's it. I do not think we ever need to actually remove them, nor to make them print annoying warnings or anything. There is nothing wrong with the functions as they stand, they just don't fit in the API anymore. We could, at some point, move them to a separate documentation page, or to the boottm of the existing one, but I feel even removing them from the documentation is unnecessary. CHANGELOG_BEGIN - [JavaScript Client Libraries] Two new methods have been added to `daml-ledger`: `streamQueries` and `streamFetchByKeys`. They are similar to the existing singular versions, except they can take multiple queries and multiple keys, respectively, and return a union of what the corresponding individual queries/keys would have. Because these new functions can do everything the existing ones can, we are deprecating the latter, though there is no plan to remove them. Upgrade path is straightforward: ``` streamQuery(t); => streamQueries(t, []); streamQuery(t, undefined); => streamQueries(t, []); streamQuery(t, q); => streamQueries(t, [q]); streamFetchByKey(t, k); => streamFetchByKey(t, [k]); ``` There is one caveat, though: `streamFetchByKeys` is a little bit less lenient in the format in which it expects the key. If your existing code was conforming to the generated TypeScript code we provide, everything should keep working, but if you were using plain JS or bypassing the TS type system, it is possible that you used to construct keys that will no longer be accepted. The new function requires all keys to be given in the _output_ format of the JSON API, which is a little bit more strict than the general JSON <-> LF conversion rules. CHANGELOG_END
garyverhaegen-da
added a commit
that referenced
this issue
Sep 8, 2020
This is an attempt to address #7034 & #7036. Strictly speaking, this does not match their acceptance criteria, as this only supports multiple queries, not mixed templates. Because the two new functions can cover the exact same use cases (and more) as the existing `streamQuery` and `streamFetchByKey`, the latter are deprecated. The deprecation cycle I suggest is to deprecate them immediately by annotating them as such in the documentation (done on this PR). That's it. I do not think we ever need to actually remove them, nor to make them print annoying warnings or anything. There is nothing wrong with the functions as they stand, they just don't fit in the API anymore. We could, at some point, move them to a separate documentation page, or to the boottm of the existing one, but I feel even removing them from the documentation is unnecessary. CHANGELOG_BEGIN - [JavaScript Client Libraries] Two new methods have been added to `daml-ledger`: `streamQueries` and `streamFetchByKeys`. They are similar to the existing singular versions, except they can take multiple queries and multiple keys, respectively, and return a union of what the corresponding individual queries/keys would have. Because these new functions can do everything the existing ones can, we are deprecating the latter, though there is no plan to remove them. Upgrade path is straightforward: ``` streamQuery(t); => streamQueries(t, []); streamQuery(t, undefined); => streamQueries(t, []); streamQuery(t, q); => streamQueries(t, [q]); streamFetchByKey(t, k); => streamFetchByKey(t, [k]); ``` There is one caveat, though: `streamFetchByKeys` is a little bit less lenient in the format in which it expects the key. If your existing code was conforming to the generated TypeScript code we provide, everything should keep working, but if you were using plain JS or bypassing the TS type system, it is possible that you used to construct keys that will no longer be accepted. The new function requires all keys to be given in the _output_ format of the JSON API, which is a little bit more strict than the general JSON <-> LF conversion rules. CHANGELOG_END
garyverhaegen-da
added a commit
that referenced
this issue
Sep 8, 2020
This is an attempt to address #7034 & #7036. Strictly speaking, this does not match their acceptance criteria, as this only supports multiple queries, not mixed templates. Because the two new functions can cover the exact same use cases (and more) as the existing `streamQuery` and `streamFetchByKey`, the latter are deprecated. The deprecation cycle I suggest is to deprecate them immediately by annotating them as such in the documentation (done on this PR). That's it. I do not think we ever need to actually remove them, nor to make them print annoying warnings or anything. There is nothing wrong with the functions as they stand, they just don't fit in the API anymore. We could, at some point, move them to a separate documentation page, or to the boottm of the existing one, but I feel even removing them from the documentation is unnecessary. CHANGELOG_BEGIN - [JavaScript Client Libraries] Two new methods have been added to `daml-ledger`: `streamQueries` and `streamFetchByKeys`. They are similar to the existing singular versions, except they can take multiple queries and multiple keys, respectively, and return a union of what the corresponding individual queries/keys would have. Because these new functions can do everything the existing ones can, we are deprecating the latter, though there is no plan to remove them. Upgrade path is straightforward: ``` streamQuery(t); => streamQueries(t, []); streamQuery(t, undefined); => streamQueries(t, []); streamQuery(t, q); => streamQueries(t, [q]); streamFetchByKey(t, k); => streamFetchByKey(t, [k]); ``` There is one caveat, though: `streamFetchByKeys` is a little bit less lenient in the format in which it expects the key. If your existing code was conforming to the generated TypeScript code we provide, everything should keep working, but if you were using plain JS or bypassing the TS type system, it is possible that you used to construct keys that will no longer be accepted. The new function requires all keys to be given in the _output_ format of the JSON API, which is a little bit more strict than the general JSON <-> LF conversion rules. CHANGELOG_END
garyverhaegen-da
added a commit
that referenced
this issue
Sep 8, 2020
This is an attempt to address #7034 & #7036. Strictly speaking, this does not match their acceptance criteria, as this only supports multiple queries, not mixed templates. Because the two new functions can cover the exact same use cases (and more) as the existing `streamQuery` and `streamFetchByKey`, the latter are deprecated. The deprecation cycle I suggest is to deprecate them immediately by annotating them as such in the documentation (done on this PR). That's it. I do not think we ever need to actually remove them, nor to make them print annoying warnings or anything. There is nothing wrong with the functions as they stand, they just don't fit in the API anymore. We could, at some point, move them to a separate documentation page, or to the boottm of the existing one, but I feel even removing them from the documentation is unnecessary. CHANGELOG_BEGIN - [JavaScript Client Libraries] Two new methods have been added to `daml-ledger`: `streamQueries` and `streamFetchByKeys`. They are similar to the existing singular versions, except they can take multiple queries and multiple keys, respectively, and return a union of what the corresponding individual queries/keys would have. Because these new functions can do everything the existing ones can, we are deprecating the latter, though there is no plan to remove them. Upgrade path is straightforward: ``` streamQuery(t); => streamQueries(t, []); streamQuery(t, undefined); => streamQueries(t, []); streamQuery(t, q); => streamQueries(t, [q]); streamFetchByKey(t, k); => streamFetchByKey(t, [k]); ``` There is one caveat, though: `streamFetchByKeys` is a little bit less lenient in the format in which it expects the key. If your existing code was conforming to the generated TypeScript code we provide, everything should keep working, but if you were using plain JS or bypassing the TS type system, it is possible that you used to construct keys that will no longer be accepted. The new function requires all keys to be given in the _output_ format of the JSON API, which is a little bit more strict than the general JSON <-> LF conversion rules. CHANGELOG_END
@garyverhaegen-da is this closed by #7066? |
@garyverhaegen-da I'll close this optimistically, please re-open if the issue has not been closed by the PR in the comment above. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
component/json-api
HTTP JSON API
team/ledger-clients
Related to the Ledger Clients team's components.
JSON API supports multiple
template, key
pairs per/v1/stream/fetch
request. See the doc: https://docs.daml.com/json-api/index.html#fetch-by-key-contracts-streamHowever TS bindings'
streamFetchByKey
is defined like this:You are actually wrapping the pair in the array:
ACs
templateId, key
pairs per requestThe text was updated successfully, but these errors were encountered: