[ 
https://issues.apache.org/jira/browse/BEAM-6241?focusedWorklogId=183759&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-183759
 ]

ASF GitHub Bot logged work on BEAM-6241:
----------------------------------------

                Author: ASF GitHub Bot
            Created on: 10/Jan/19 15:52
            Start Date: 10/Jan/19 15:52
    Worklog Time Spent: 10m 
      Work Description: iemejia commented on issue #7293: [BEAM-6241] Added 
limit and aggregates support to MongoDbIO
URL: https://github.com/apache/beam/pull/7293#issuecomment-453145486
 
 
   Hehe that Zelda game is pure dope.
   
   I understand your point this looks like a tradeoff of usability 
(`QueryBuilder`) vs extensability (`SerializableFunction`). This does not 
change a lot save for the fact that if in the future there is a new filter / 
predicate / special condition the user wants to hack not covered by 
QueryBuilder, the user can override the function version without waiting for a 
change upstream.
   
   What I would like to avoid is having more `withLike` methods in Read to 
configure a "query". I think it is way better to have a common function/object 
that wraps all that configuration as you did with `QueryBuilder` :+1:  and not 
to have more `withXXX` (motivated by maintainability).
   
   I see your point on the Pipeline/Aggregations API but if this is covered by 
`withQuery` and parameterize via `QueryBuilder` we avoid a duplicate method, so 
let’s make this if you agree, we refactor this to have `withQuery` as I 
proposed and in the docs we mention that we provide a de-facto `QueryBuilder` 
implementation to ease its use. We should use that object in the tests too as 
an example. 
   
   I think we can even arrive to the point where we can even deprecate the 
other query related `withXXX` configuration methods and unify the query API on 
withQuery(SerializableFunction) (with the public `QueryBuilder` as a user 
friendly version of that function. WDYT? Am I missing probably some particular 
use case or issue with this idea?
   
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


Issue Time Tracking
-------------------

    Worklog Id:     (was: 183759)
    Time Spent: 1h 10m  (was: 1h)

> MongoDbIO - Add Limit and Aggregates Support
> --------------------------------------------
>
>                 Key: BEAM-6241
>                 URL: https://issues.apache.org/jira/browse/BEAM-6241
>             Project: Beam
>          Issue Type: Improvement
>          Components: io-java-mongodb
>    Affects Versions: 2.9.0
>            Reporter: Ahmed El.Hussaini
>            Assignee: Ahmed El.Hussaini
>            Priority: Major
>              Labels: easyfix
>          Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> h2. Adds Support to Limit Results
>  
> {code:java}
> MongoDbIO.read()
> .withUri("mongodb://localhost:" + port)
> .withDatabase(DATABASE)
> .withCollection(COLLECTION)
> .withFilter("{\"scientist\":\"Einstein\"}")
> .withLimit(5));{code}
> h2. Adds Support to Use Aggregates
>  
> {code:java}
> List<BsonDocument> aggregates = new ArrayList<BsonDocument>();
>   aggregates.add(
>     new BsonDocument(
>       "$match",
>       new BsonDocument("country", new BsonDocument("$eq", new 
> BsonString("England")))));
> PCollection<Document> output =
>   pipeline.apply(
>     MongoDbIO.read()
>       .withUri("mongodb://localhost:" + port)
>       .withDatabase(DATABASE)
>       .withCollection(COLLECTION)
>       .withAggregate(aggregates));
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to