Guides¶

Reference-shaped pages on the things that are more design than procedure.

Datasets ¶

Every dataset that ships with connecto, what it is, what it can do, and its particular idiosyncrasies.

Capabilities ¶

Why min_score=100 raises on MICrONS instead of being ignored, and how to write code that adapts.

Adding a dataset ¶

Point connecto at any CAVE datastack or neuPrint server, with or without writing a class.

Caching ¶

What is cached, where, and why the cache key can never serve you the wrong materialization.

When the server is down ¶

CAVE answers 503 for hours while it materializes. What that looks like, how to tell it apart from a dead VPN, and how to wait it out.

The one-paragraph architecture¶

Backends implement ten _fetch_* hooks that return raw frames. Everything you actually touch — version resolution, capability checking, caching, column renaming, dtype coercion, unit conversion, error translation — happens above them, once, in code both backends share.

A backend never constructs a user-facing DataFrame. That is not a style preference; it is the only thing that structurally guarantees FlyWire and hemibrain hand back the same frame. If normalisation lived in the backends, there would be two implementations of it, and they would drift.

          ds.connectivity.edges("DA1_lPN")
                      |
        [ capability gate + auth translation ]     core/dataset.py
                      |
        [ version resolution, ID resolution ]      core/criteria.py
                      |
              ds._fetch_edges(...)                 <- the ONLY backend code
                      |
        [ rename, coerce, rescale, stamp ]         core/schemas.py
                      |
              pre, post, weight

Adding a backend means writing ten methods. It does not mean touching any of the normalisation.

Guides¶

Datasets¶

Capabilities¶

Adding a dataset¶

Caching¶

When the server is down¶