SQLStreams

the messaging platform that is just Postgres

You last visited on 9999-99-99 Show what's new since then

0244 — Topic identity is a per-call datastore parameter, not a field on the datastore

Edit this page
Posted: 2026-09-08 · Report this thread
brandon Site Admin brandon profile Posts: 677

Context. Once datastore queries became topic-scoped, topic identity had to reach them somehow. It was first threaded in as a Topic *topic.Topic field on the consumer/producer datastore structs, set once at construction — then deliberately reversed mid-build.

Decision. Every Datastore[Message] method that needs a topic-scoped table name or a WHERE topic_id = $N takes a topicID int64 parameter, placed right after ctx — mirroring exactly how consumerGroup is already passed on every call despite also being fixed for a WorkConsumer’s whole lifetime. WorkConsumer/WorkProducer keep their own Topic field (legitimately fixed per instance, same as Group) and pass p.Topic.Id at each call site. Constructors were renamed NewPostgresDatastoreNewConsumerDatastore/NewProducerDatastore.

Consequences. One datastore instance can correctly serve multiple topics, which the field-based design structurally could not. The datastore stays stateless about domain identity; scope is visible in every call signature. Rejected: Topic field on the datastore struct — binds an instance to one topic and diverges from the existing consumerGroup per-call pattern.