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

Connectathon Issues with Bulkdata #67

Closed
prb112 opened this issue Sep 14, 2019 · 4 comments
Closed

Connectathon Issues with Bulkdata #67

prb112 opened this issue Sep 14, 2019 · 4 comments
Assignees
Labels
bug Something isn't working
Milestone

Comments

@prb112
Copy link
Contributor

prb112 commented Sep 14, 2019

Connectathon Issues with Bulkdata

@prb112
Copy link
Contributor Author

prb112 commented Sep 14, 2019

resolving ds issue and tenant issue with Albert

albertwang-ibm added a commit that referenced this issue Sep 14, 2019
Signed-off-by: Albert Wang <xuwang@us.ibm.com>
prb112 added a commit that referenced this issue Sep 14, 2019
Signed-off-by: Paul Bastide <pbastide@us.ibm.com>
prb112 added a commit that referenced this issue Sep 14, 2019
Signed-off-by: Paul Bastide <pbastide@us.ibm.com>
lmsurpre added a commit that referenced this issue Sep 14, 2019
issue #67 fix fhir tenant issue
lmsurpre added a commit that referenced this issue Sep 14, 2019
Connectathon Issues with Bulkdata #67
albertwang-ibm added a commit that referenced this issue Sep 14, 2019
Signed-off-by: Albert Wang <xuwang@us.ibm.com>
lmsurpre added a commit that referenced this issue Sep 14, 2019
issue #67 change file path in COS
albertwang-ibm added a commit that referenced this issue Sep 14, 2019
Signed-off-by: Albert Wang <xuwang@us.ibm.com>
lmsurpre added a commit that referenced this issue Sep 14, 2019
issue #67 change importchunkjob to take tenant and storeID
albertwang-ibm added a commit that referenced this issue Sep 14, 2019
Signed-off-by: Albert Wang <xuwang@us.ibm.com>
lmsurpre added a commit that referenced this issue Sep 14, 2019
issue #67 add org.json to javabatchjob war
albertwang-ibm added a commit that referenced this issue Sep 15, 2019
Signed-off-by: Albert Wang <xuwang@us.ibm.com>
albertwang-ibm added a commit that referenced this issue Sep 15, 2019
Signed-off-by: Albert Wang <xuwang@us.ibm.com>
albertwang-ibm added a commit that referenced this issue Sep 15, 2019
Signed-off-by: Albert Wang <xuwang@us.ibm.com>
albertwang-ibm added a commit that referenced this issue Sep 15, 2019
Signed-off-by: Albert Wang <xuwang@us.ibm.com>
albertwang-ibm added a commit that referenced this issue Sep 15, 2019
Signed-off-by: Albert Wang <xuwang@us.ibm.com>
lmsurpre added a commit that referenced this issue Sep 15, 2019
issue #67 remove shared jar from jobbatch war
albertwang-ibm added a commit that referenced this issue Sep 15, 2019
Signed-off-by: Albert Wang <xuwang@us.ibm.com>
albertwang-ibm added a commit that referenced this issue Sep 15, 2019
Signed-off-by: Albert Wang <xuwang@us.ibm.com>
@lmsurpre
Copy link
Member

Once we finally started testing with a partner, we hit a few issues where we returned 400 error when it was actually a server error. This was frustrating to user and made it harder for him to trust us when we rejected other requests with the same error (even those really were client issues).
We really need to default unexpected exceptions to 500.

@lmsurpre
Copy link
Member

lmsurpre commented Sep 15, 2019

Separate thought...I don't think we need to be appending each resources into a big string. Can we buffer the objects on their way into ObjectStore instead? Is there a better way to handle it via java batch?

lmsurpre added a commit that referenced this issue Sep 15, 2019
albert was mislead by the slide deck.  json shouldn't be wrapped in '[
]' and no commas between lines

also we should use Generator and not toString for writing objects

Signed-off-by: lmsurpre <lmsurpre@us.ibm.com>
lmsurpre added a commit that referenced this issue Sep 15, 2019
Signed-off-by: lmsurpre <lmsurpre@us.ibm.com>
lmsurpre added a commit that referenced this issue Sep 15, 2019
@prb112
Copy link
Contributor Author

prb112 commented Sep 16, 2019

Once we finally started testing with a partner, we hit a few issues where we returned 400 error when it was actually a server error. This was frustrating to user and made it harder for him to trust us when we rejected other requests with the same error (even those really were client issues).
We really need to default unexpected exceptions to 500.

Sure - I think we consider this part of refactoring.

@prb112 prb112 added this to the Sprint 1 milestone Sep 16, 2019
@prb112 prb112 added the bug Something isn't working label Sep 16, 2019
@prb112 prb112 closed this as completed Sep 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants