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

[Tables] Reconcile real-time and historical tables #1077

Closed
akhenry opened this issue Jul 5, 2016 · 6 comments
Closed

[Tables] Reconcile real-time and historical tables #1077

akhenry opened this issue Jul 5, 2016 · 6 comments
Assignees
Milestone

Comments

@akhenry
Copy link
Contributor

akhenry commented Jul 5, 2016

Currently tables are implemented as two different components. These should be reconciled into a single component that shows both historical and real-time values and observes time-conductor bounds.

@akhenry akhenry self-assigned this Jul 5, 2016
@akhenry akhenry added this to the Niven milestone Jul 5, 2016
@akhenry akhenry modified the milestones: Orwell, Niven Aug 2, 2016
@akhenry akhenry modified the milestones: Orwell, Pratchett Aug 15, 2016
@akhenry akhenry removed this from the Pratchett milestone Sep 27, 2016
@akhenry
Copy link
Contributor Author

akhenry commented Sep 27, 2016

Clearing milestone, deferring this until the new telemetry API is merged.

@larkin larkin added this to the Robinson milestone Oct 18, 2016
@larkin
Copy link
Contributor

larkin commented Oct 18, 2016

Moved to Robinson, discuss in sprint planning if we want to defer to Roddenberry.

@charlesh88
Copy link
Contributor

My two cents: we need to stop deferring this, it has a significant impact for certain deployments. WARP, for example, will have both Historic and Real-time Tables. RT tables will work fine; Historic Tables won't work at all. Providing objects and views that will fail for no reason apparent to the user undermines trust in the system at a pretty fundamental level and we should try very hard to avoid this situation.

@akhenry
Copy link
Contributor Author

akhenry commented Oct 18, 2016

@charlesh88 agreed, and it's high on my priority list. In principle, it's totally doable for Robinson, but there may be some iterations on the telemetry API that might delay things a little beyond that. Hopefully not though.

In the worst case, they could be split into separate bundles, which would allow historical to be disabled in WARP. That would be a five minute job.

@charlesh88 charlesh88 modified the milestones: Simmons, Shelley Jan 24, 2017
akhenry added a commit that referenced this issue Feb 10, 2017
…bles

Added batch processing of large historical queries. #1077
@charlesh88 charlesh88 modified the milestones: Simmons, Stephenson Feb 14, 2017
larkin pushed a commit that referenced this issue Feb 16, 2017
Squashed commit of the following:

commit 34dc457
Author: Henry <[email protected]>
Date:   Fri Feb 10 15:35:17 2017 -0800

    [Tables] Restored telemetry datum field 'name'. Fixed bug with default sort not working

commit a3311e4
Author: Henry <[email protected]>
Date:   Thu Jan 26 10:59:22 2017 -0800

    [Tables] Tests and style fixes

commit ef8efbd
Author: Henry <[email protected]>
Date:   Wed Jan 25 15:41:08 2017 -0800

    [Tables] Default UTC time system if available and none others defined

commit 6cd99ef
Author: Henry <[email protected]>
Date:   Mon Jan 23 12:43:59 2017 -0800

    [Tables] Added telemetry buffer so that subscription data is not discarded if it's beyond the end bounds

commit ae2b73a
Author: Henry <[email protected]>
Date:   Thu Jan 19 21:18:53 2017 -0800

    [Tables] Increase default table size

commit 0c3ff82
Author: Henry <[email protected]>
Date:   Tue Jan 17 14:44:09 2017 -0800

    [Table] Added ticking to combined historical/real-time table

    Don't add duplicate telemetry data

commit 50f303b
Author: Henry <[email protected]>
Date:   Sun Jan 15 10:59:28 2017 -0800

    [Tables] limit digests to increase performance

commit 2a4944d
Author: Henry <[email protected]>
Date:   Fri Dec 16 16:34:41 2016 -0800

    [Tables] Refactoring for consolidation of historical and real-time tables

    Added batch processing of large historical queries. #1077

commit 3544caf
Author: Henry <[email protected]>
Date:   Thu Dec 15 15:21:45 2016 -0800

    [API] Observer path was accessing object key incorrectly

commit 976333d
Author: Henry <[email protected]>
Date:   Tue Dec 6 18:04:47 2016 -0800

    [Tables] Support for subscriptions from new Telemetry API

    Historical and real-time data flowing

    Added formatting, and limits. Support telemetry objects themselves and not just composition of telemetry objects

    Apply default time range if none supplied (15 minutes)

commit 6d5530b
Author: Henry <[email protected]>
Date:   Tue Dec 6 12:08:52 2016 -0800

    [Tables] Using new composition API to fetch all telemetry objects
@charlesh88 charlesh88 modified the milestones: Stephenson, Sterling Mar 6, 2017
@akhenry akhenry closed this as completed Mar 7, 2017
@charlesh88
Copy link
Contributor

@akhenry @VWoeltjen Definitely need some testing notes here for Testathons. I only see a single Telemetry Table object in the Create menu; hoping that means this is complete.

@VWoeltjen
Copy link
Contributor

Verified during testathon 2017-10-05; Telemetry Table includes both real-time and historical data

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

No branches or pull requests

4 participants