[
https://issues.apache.org/jira/browse/BEAM-6241?focusedWorklogId=183760&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-183760
]
ASF GitHub Bot logged work on BEAM-6241:
----------------------------------------
Author: ASF GitHub Bot
Created on: 10/Jan/19 15:55
Start Date: 10/Jan/19 15:55
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 configuration methods e.g. `withProjection`, `withFilter`
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: 183760)
Time Spent: 1h 20m (was: 1h 10m)
> 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 20m
> 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)
