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

Support conversion of time series storage #59

Open
daniel-thom opened this issue Dec 4, 2024 · 0 comments
Open

Support conversion of time series storage #59

daniel-thom opened this issue Dec 4, 2024 · 0 comments

Comments

@daniel-thom
Copy link
Collaborator

daniel-thom commented Dec 4, 2024

We need the ability to convert the data in a System's time series storage object to a different type. We currently have InMemoryTimeSeriesStorage and ArrowTimeSeriesStorage. We will soon have ChronifyTimeSeriesStorage, which will have these options:

  • DuckDB in-memory database
  • DuckDB file database
  • SQLite in-memory database
  • SQLite file database

We will need simple conversion between all types. One idea is an interface like this:

class System
    def convert_time_series_storage(self, replace=True, **time_series_kwargs) -> TimeSeriesStorageBase:
        """Construct a new time series storage object that has a copy of all data from the existing storage.

        Parameters
        -----------
        replace
            Replace the existing storage object after the copy.
        time_series_kwargs
            Same time-series kwargs that can be passed to a System constructor.

Suppose there is an existing system with in-memory time series storage. This example would serialize all time arrays to a directory with Arrow files.

system.convert_time_series_storage(time_series_directory="my-time-series")

Questions:

  1. Is the default behavior with replace correct?
  2. If replace is false, how do we connect the storage to a system later?
  3. The reason that this example signature uses kwargs is that users do not currently interact directly with the time series storage classes. Should we do something different in light of support for chronify?
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

1 participant