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

Extend table API to support duplicating tables #453

Closed
kgodey opened this issue Jul 20, 2021 · 6 comments
Closed

Extend table API to support duplicating tables #453

kgodey opened this issue Jul 20, 2021 · 6 comments
Labels
ready Ready for implementation type: enhancement New feature or request work: backend Related to Python, Django, and simple SQL

Comments

@kgodey
Copy link
Contributor

kgodey commented Jul 20, 2021

Problem

The design spec for Basic Table Operations calls for the ability to duplicate a table.

Proposed solution

The Table creation endpoint should be extended to accept a reference to another table and whether all data should be copied. If this parameter is passed in, it should create a new table that's a copy of the table that has been passed in. Data should be copied conditionally according to the parameter that has been passed in.

Additional context

@kgodey kgodey added the type: enhancement New feature or request label Jul 20, 2021
@kgodey kgodey added this to the 09. Data Modeling milestone Jul 20, 2021
@kgodey kgodey added ready Ready for implementation work: backend Related to Python, Django, and simple SQL work: database labels Jul 20, 2021
@bohemia420
Copy link
Contributor

@kgodey there can be 3 possibilities IMO,

  • clone (schema, constraints only) clone (schema, constraints+data)
  • (deep) copy

agree? or is it just clone and reference, to begin with?

@kgodey
Copy link
Contributor Author

kgodey commented Sep 27, 2021

@bohemia420 What do you anticipate being copied in a "deep copy" that isn't covered by the first two options?

@bohemia420
Copy link
Contributor

say a table A with shape -[100,4] i.e 100 rows 4 cols. creating a table B could be:

  • table B shaped [0, 4] i.e just copied the schema.
  • table B shaped [100, 4] i.e copied schema + data. Should there be filters/parameters, shape may be [x, 4] where x <= 100
    these are the first two options.

the "deep copy" may actually be more of a "view", which albeit [100, 4] or as per a filter say [x, 4] where x <= 100, but any changes to table B will also be reflected in table A. IMO, I don't think much such cases. One real life has been an alerts table primarily comprising ALARMS and STATUS OKs.
we had had a projection (type=ALARM) so we only look at ALARMs in an otherwise table of "STATUS OKs", and as we'd resolve the ALARMs (over a UI), both these tables A and B 'd get updated.

TL;DR - honoring simplicity, we should be good with first two cases only.

@kgodey
Copy link
Contributor Author

kgodey commented Sep 27, 2021

@bohemia420 We'd want users to make a view for cases where they want data automatically updated from other tables, see #442 for issues related to that. This issue already covers the first two options so we should be good.

@github-actions
Copy link

This issue has not been updated in 90 days and is being marked as stale.

@github-actions github-actions bot added the stale label Apr 15, 2022
@kgodey
Copy link
Contributor Author

kgodey commented Apr 16, 2022

I'm going to close this, we can reopen or open a new issue once we have a more detailed design for it.

@kgodey kgodey closed this as completed Apr 16, 2022
@kgodey kgodey removed this from the [Beta] Data Modeling milestone Jun 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready Ready for implementation type: enhancement New feature or request work: backend Related to Python, Django, and simple SQL
Projects
No open projects
Development

No branches or pull requests

2 participants