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

Provider API: Add a "recorded" field to status changes #307

Closed
2 of 6 tasks
lionel-panhaleux opened this issue May 3, 2019 · 6 comments · Fixed by #329
Closed
2 of 6 tasks

Provider API: Add a "recorded" field to status changes #307

lionel-panhaleux opened this issue May 3, 2019 · 6 comments · Fixed by #329
Milestone

Comments

@lionel-panhaleux
Copy link
Contributor

Is your feature request related to a problem? Please describe.

Polling status changes using the timestamp field is unreliable: an event can be recorded late, and ignored by the polling system if it uses the timestamp of the last polled event to fetch new ones.

Describe the solution you'd like

Adding a recorded field in the status changes, and a query parameter in the status_changes/ endpoint to query the events using this information.

Is this a breaking change

  • Yes, breaking
  • No, not breaking
  • I'm not sure

Provider or agency

For which API is this feature being requested:

  • provider
  • agency
  • both

Describe alternatives you've considered

A global sequence ID seems less natural and would not convey the additional "time of recording" information.

Additional context

The idea has been tested with our partners and is satisfactory. We would love to see it in MDS 0.4

@billdirks
Copy link
Contributor

I don't understand what recorded is. What is its type and what values can it contain?

@lionel-panhaleux
Copy link
Contributor Author

A better naming would be welcome :-) I was thinking a timestamp: the time when the event was recorded, ie. made available through the Provider API.

@billdirks
Copy link
Contributor

Thanks for the clarification!

@dyakovlev
Copy link
Contributor

some notes from the 5/9 call:

  • suggestion was well received, mutual agreement that it addresses a problem experienced by many consumers
  • alternative field wording: publication_time or published_time (to mirror event_time)
  • this should be applied to the trips endpoint as well
  • release-wise, this can be made optional in 0.3.x line but making it required would need to target 0.4.x

@lionel-panhaleux - sounds like this should move forward into a PR if possible!

@hunterowens hunterowens added this to the 0.3.2 milestone May 21, 2019
rf- added a commit to remix/mobility-data-specification that referenced this issue Jun 11, 2019
These fields will be optional in 0.3.2 and mandatory in a future
version. They reflect the time that the provider made the relevant data
available through the API.

This commit partially fixes openmobilityfoundation#307, but it's not a complete fix since it
doesn't include the ability to query by publication time.
rf- added a commit to remix/mobility-data-specification that referenced this issue Jun 11, 2019
These fields will be optional in 0.3.2 and mandatory in a future
version. They reflect the time that the provider made the relevant data
available through the API.

This commit partially fixes openmobilityfoundation#307, but it's not a complete fix since it
doesn't include the ability to query by publication time.
hunterowens pushed a commit that referenced this issue Jun 12, 2019
These fields will be optional in 0.3.2 and mandatory in a future
version. They reflect the time that the provider made the relevant data
available through the API.

This commit partially fixes #307, but it's not a complete fix since it
doesn't include the ability to query by publication time.
@rf-
Copy link
Contributor

rf- commented Jun 12, 2019

That happened automatically because I referenced this issue in the PR, but y’all might want to reopen this issue to track making the field mandatory and adding the ability to query by it

@hunterowens
Copy link
Collaborator

I think maybe that is worth creating a new issue to track that under the 0.4.0 milestone

Zatte pushed a commit to voiapp/mobility-data-specification that referenced this issue Jul 10, 2019
These fields will be optional in 0.3.2 and mandatory in a future
version. They reflect the time that the provider made the relevant data
available through the API.

This commit partially fixes openmobilityfoundation#307, but it's not a complete fix since it
doesn't include the ability to query by publication time.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants