[ 
https://issues.apache.org/jira/browse/BEAM-9856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacob Ferriero updated BEAM-9856:
---------------------------------
    Description: 
Currently the List Messages API paginates through in a single ProcessElement 
Call.
However we could get a restriction based on createTime using Messages.List 
filter and orderby.
 

This is inline with the future roadmap of  HL7v2 bulk export API becomes 
available that should allow splitting on (e.g. create time dimension). 
Leveraging this bulk export might be  a future optimization to explore.
 

This could look like paginating through each hour of data w/ in the time frame 
that the store spans, in a separate thread.

 

  was:
Currently the List Messages API paginates through in a single ProcessElement 
Call.

 

In the future if a bulk export API becomes available that would allow splitting 
on some dimension (e.g. create time), this should be refactored as a splittable 
DoFn or at least run several sub queries so that we are not listing an entire 
store in a single thread.

 

This could look like paginating through each hour of data w/ in the time frame 
that the store spans, in a separate thread.

 


> HL7v2IO.ListHL7v2Messages should be refactored as splitable DoFn
> ----------------------------------------------------------------
>
>                 Key: BEAM-9856
>                 URL: https://issues.apache.org/jira/browse/BEAM-9856
>             Project: Beam
>          Issue Type: Improvement
>          Components: io-java-gcp
>            Reporter: Jacob Ferriero
>            Assignee: Jacob Ferriero
>            Priority: Minor
>
> Currently the List Messages API paginates through in a single ProcessElement 
> Call.
> However we could get a restriction based on createTime using Messages.List 
> filter and orderby.
>  
> This is inline with the future roadmap of  HL7v2 bulk export API becomes 
> available that should allow splitting on (e.g. create time dimension). 
> Leveraging this bulk export might be  a future optimization to explore.
>  
> This could look like paginating through each hour of data w/ in the time 
> frame that the store spans, in a separate thread.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to