fix test (with a skip)

1 files changed, 0 insertions, 34 deletions

diff --git a/next_thoughts.txt b/next_thoughts.txt
deleted file mode 100644
index 8c7d12fc..00000000
--- a/next_thoughts.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-
-Should probably just UUID all the (public) ids.
-
-Instead of having a separate id pointer table, could have an extra "mutable"
-public ID column (unique, indexed) on entity rows. Backend would ensure the
-right thing happens. Changelog tables (or special redirect/deletion tables)
-would record changes and be "fallen through" to.
-
-Instead of having merge redirects, could just point all identifiers to the same
-revision (and update them all in the future). Don't need to recurse! Need to
-keep this forever though, could scale badly if "aggregations" get merged.
-
-Redirections of redirections should probably simply be disallowed.
-
-"Deletion" is really just pointing to a special or null entity.
-
-Trade-off: easy querying for common case (wanting "active" rows) vs. robust
-handling of redirects (likely to be pretty common). Also, having UUID handling
-across more than one table.
-
-## Scaling database
-
-Two scaling issues: size of database due to edits (likely billions of rows) and 
-desire to do complex queries/reports ("analytics"). The later is probably not a
-concern, and could be handled by dumping and working on a cluster (or secondary
-views, etc). So just a distraction? Simpler to have all rolled up.
-
-Cockroach is postgres-like; might be able to use that for HA and scaling?
-Bottlenecks are probably complex joins (mitigated by "interleave"?) and bulk
-import performance (one-time?).
-
-Using elastic for most (eg, non-logged-in) views could keep things fast.
-
-Cockroach seems more resourced/polished than TiDB?