Skip to content
This repository has been archived by the owner on Mar 11, 2023. It is now read-only.

Support all standard params for filter, sample statuses and user events #165

Merged
merged 1 commit into from
Oct 24, 2017

Conversation

allantl
Copy link
Contributor

@allantl allantl commented Oct 21, 2017

This PR :

  • Partially addresses Support all standard params for Streaming requests #71. Reference: Basic stream parameters

    • site events
    • filter statuses
    • sample statuses
    • firehose statuses
    • user events

    As I don't have access to both of these stream endpoints, Im not confident to modify it since I can't do the UAT.
    Plus I can't find the documentation for this two endpoints.
    FYI, User streams and Site streams will be deprecated some time in the future. See here.

  • Fix Clarify TwitterStatusClient scaladoc #130

    I don't think we should mention comma-separated in the docs since that is basically hidden behind the API.
    Also, I removed most of the links which are not active anymore.

  • Fix locations parameters

    It needs to be a list of longitude,latitude pairs. I added the encoder for list of tuples as well.

@codecov
Copy link

codecov bot commented Oct 21, 2017

Codecov Report

Merging #165 into master will increase coverage by 0.02%.
The diff coverage is 88.88%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #165      +/-   ##
==========================================
+ Coverage    92.4%   92.42%   +0.02%     
==========================================
  Files          69       70       +1     
  Lines        1119     1122       +3     
  Branches       16       16              
==========================================
+ Hits         1034     1037       +3     
  Misses         85       85
Impacted Files Coverage Δ
...tp/clients/streaming/sites/TwitterSiteClient.scala 100% <ø> (ø) ⬆️
...fregola/twitter4s/entities/enums/FilterLevel.scala 100% <100%> (ø)
...tp/clients/streaming/users/TwitterUserClient.scala 100% <100%> (ø) ⬆️
...ients/streaming/statuses/TwitterStatusClient.scala 100% <100%> (ø) ⬆️
...egola/twitter4s/http/marshalling/BodyEncoder.scala 90% <66.66%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8cdcdc8...f578a01. Read the comment docs.

@DanielaSfregola
Copy link
Owner

Hi @allantl for your awesome PR!

Overall look ok, but I cannot merge it because of the fix on locations -- it's a breaking change.

Any chance you could separate the fix for location in a separate PR? This way we could release the rest in the next release without any breaking change

*/
def filterStatuses(follow: Seq[Long] = Seq.empty,
tracks: Seq[String] = Seq.empty,
locations: Seq[Double] = Seq.empty,
locations: Seq[(Double, Double)] = Seq.empty,
Copy link
Owner

@DanielaSfregola DanielaSfregola Oct 22, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably we should use a case class here rather than simple tuples....but how should we call it? we already have a case class Location (that is quite different) and used in the REST Client

Copy link
Contributor Author

@allantl allantl Oct 24, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are some improvements that can be made here. Looking at the official twitter java client which is quite outdated here, seems that each bounding box location must be in the form of (southwest coordinate, northeast coordinate).

We can create case classes similar to the link above. Not sure about the name though. For reference, elasticsearch has similar usecase.

Also, looking at this doc, most coordinates are in the form of [LONG,LAT], except geo attribute [LAT, LONG], we can improve case classes such as Area, Coordinates. It would be another breaking change.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't worry too much about breaking changes: as long as we document them and that they are done with reason, then people are gonna be fine with it. The problem is that we need to do them, bump up the version and properly document them.

We have a few requests already that we know are probably gonna need API breaking changes, for example see #142 and #144.

I am gonna move this discussion into a separate issue (see #169) so that we can discuss it more easily.

@allantl
Copy link
Contributor Author

allantl commented Oct 23, 2017

Yes sure, I'll create another PR for the locations fix.

@DanielaSfregola
Copy link
Owner

@allantl could you please rebase this PR and maybe separate the location fix in another PR?

Thanks!

@allantl
Copy link
Contributor Author

allantl commented Oct 24, 2017

@DanielaSfregola All done!

Copy link
Owner

@DanielaSfregola DanielaSfregola left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @allantl,
thanks for your contribution!

LGTM

@DanielaSfregola DanielaSfregola merged commit 723bc1c into DanielaSfregola:master Oct 24, 2017
@DanielaSfregola DanielaSfregola added this to the 5.2 milestone Oct 24, 2017
@allantl allantl deleted the feature/71 branch October 24, 2017 15:50
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants