Skip to content

Always Be Saving #42

Open
Open

Description

@nickzoic

Working on datasets in Countess I find myself adding "Save CSV" plugins scattered all over the place, to store intermediate results, which obscures the flow of data quite a lot.

For example, compare these:

Before After
x y

Maybe it'd be more sensible to have an automatic "Save As" at the bottom of every node to reduce clutter?

Plus (maybe) saving intermediate results would be an efficient way to handle regeneration of data?

Activity

  1. changed the title [-]Always Saving[/-] [+]Always Be Saving[/+] on Oct 25, 2024
  2. afrubin commented on Mar 12, 2026

    @afrubin

    Yeah I think this is a good idea to add an "Output to CSV" checkbox for every node.

    Rather than "Save As" that implies the user should provide their own file path/file name, we should automatically generate this file name and put it in a csv/ directory under the associated working directory for the pipeline (that is set globally for the whole run). The automatic file names would start with the datetime and then have a mutated version of the plugin name (kebab case? underscores?). Note that this may constrain what characters are allowed to exist in the plugin names, or certain invalid characters could just be stripped out.

  3. added this to the Preprint milestone on Mar 12, 2026
  4. nickzoic commented on Mar 13, 2026

    @nickzoic
    CollaboratorAuthor

    Hmmm, interesting, any step which saves as CSV can of course be retrieved as CSV which could be used to restart partial computation but I wonder if we'd be better off saving these intermediate files as something more flexible & efficient like parquet, or just persisting data to a DuckDB database.

  5. afrubin commented on Mar 13, 2026

    @afrubin

    Hmmm, interesting, any step which saves as CSV can of course be retrieved as CSV which could be used to restart partial computation but I wonder if we'd be better off saving these intermediate files as something more flexible & efficient like parquet, or just persisting data to a DuckDB database.

    I see these as serving two very different purposes. The CSV is for people who want to inspect/plot an intermediate artefact, and parquet is for resuming workflows (which I agree is a good thing to have). So maybe the answer is both?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions