Evento

One SwiftUI target with the city compiled into it. VenueNormalizer resolved venue names through about forty contains branches; categories were collapsed by hand, mapping "Concerts" onto "Music" and "Art" onto "Exhibition"; a 287-line parser decided on the device whether a description was a timetable and where its columns were.

Why it did not last. Not because it was slow — it was fine. Because every rule was invisible and every fix needed a release. The next build was mostly about undoing this.

Postgres becomes the source of truth. The design question that shaped everything after it: what makes two rows the same event?

The answer taken here is that identity is asserted, not inferred. Every source must present a stable external id, and ingest_event() — the single write path — matches on it. A re-scrape updates a row; it never adds one. Where two different sources describe the same night, that is a separate problem, solved later and deliberately conservatively (see Identity Numbers).

event_sources arrives in the same build, so an event can be credited to more than one provider without any of them owning it. And the review gate: a source the system discovers imports as drafts until a person enables it.

The bug that set the tone. Migration 001 is four lines. Ticketmaster sends '' rather than null for a description it does not have, and coalesce() only guards against null — so every re-import was overwriting descriptions somebody had written with nothing.

Twenty-five migrations in two days, and the largest single idea in the project: the matching rules stop being code and become rows.

venue_aliases holds every spelling that resolves to a venue. rooms.match_keywords holds every phrase that means a particular hall. Both were seeded directly from the Swift tables being deleted in the same build, so nothing was lost in the move. Thirty-five venue fragments — one building under several names — were consolidated, each merge snapshotted so it can be read back.

Matching a room is a good example of why data beats code here. The rule is "the longest matching keyword wins", because sala 4 alicia de larrocha is a more specific claim than a bare sala 4. Expressed as a query that is one order by; expressed as branches it is a maintenance problem in three languages.

The second idea in this build is the same one applied to presentation: the home screen becomes sections and section_events rows. A shelf is created in the back office, not in a Swift file, and its layout — carousel or list — is a column.

Also here: one canonical category per bucket, batch editing as a transactional audited function, and the app's first test target.

Until now the client paged. This build changed the strategy to fetch everything once — about seven megabytes — and answer every subsequent question locally.

The reasoning: search, the map, the category pills and the date filters are all predicates over the same set. Serving them from the network means a request per keystroke and per pan, a loading state in six places, and an offline app that shows nothing. Holding the set means one request, one loading state, and a catalogue that survives a tunnel.

It also forced a correctness fix. Paging needs a total order, and is_featured desc, starts_at asc is not one when 1,829 events share a start instant — two requests disagreed about which row came first, so offset paging skipped and repeated. Adding id as a final tie-break made the order total.

On the client side this is where the event page took its present shape: the page colour is sampled from the bottom edge of the hero image, so the photograph continues into the page rather than sitting on a panel. A hero can be a video with the image as its still. Highlights became a shelf of cards rather than one full-width banner, because a banner can only show one thing and took 190 points to do it.

The busiest two days — 36 commits on the 12th. The theme is what happens when a person and an importer disagree.

The model: a manual edit sets is_locked, and a lock stops an automatic import overwriting that row. It is not meant to stop the person who made the correction, so merge_reviewed_pair() lets an editor lift a lock and merge inside one transaction, writing the lift to audit_log first. The record survives and the merge stays reversible.

Refinements to that rule followed as the edges appeared: a lock should protect what a person wrote, not a blank (064); and a lock should mean somebody actually changed something, not that a form was opened and saved (065).

merge_venues was consolidated into one function in this build. The previous two-argument overload was still live and silently destroyed three things — no venue_merges snapshot, no aliases carried across, no street aliases — and PostgREST could resolve either overload depending on the arguments sent.

Four venues started publishing their own programmes here, each needing its own adapter: the Palau de la Música draws its listing in the browser from a JSON feed, Apolo's agenda is an infinite scroll whose rows carry no year, and both Teatre Lliure houses list runs whose individual performances live only on the box office.

Seventeen migrations, almost all of them rules about what a listing means.

The programme parser moves to lib/programme.ts with the tests written for it, and events.programme stores what it found as JSON. The client decodes a structure instead of parsing prose. An editor can also override the source text in programme_text and watch it re-parse in a live preview before saving — the correction is read by exactly the same rules as the original, rather than becoming a second format nobody can check.

The other rules in this build are all of the same kind — a statement about the domain, written once, applied to the whole catalogue:

• 053 — a VIP package is not an event; it is a ticket for the performance it is sold for.
• 062 — a night already stored as a session of a run is not a second event.
• 066 — a badge comes from what a listing states, not from a phrase in a biography.
• 068 — a show with no picture of its own borrows its cycle's.
• 069 — a free cycle makes its nights free unless one of them says otherwise.

has_profile had drifted. It started as "somebody curated this one" and became the gate on public_venues, which meant 656 of 688 venues had no page and could not be edited. Every venue has one now, and is_featured takes over the editorial job: it decides the Popular Venues shelf and which venues draw their own mark on the map.

That flip had a trap in it worth recording. is_placeholder_venue — which the event duplicate finder uses to skip street stand-ins — tested not has_profile. Setting the column true everywhere would have made that function return false for every row in the table, silently, and widened the duplicate finder to every geocoded street corner in Barcelona. The guard was restated as what it had always been reaching for: a venue with a picture or a description is a real place.

Halls stop being venues

extract_room_venues() finds venues named Building — Hall, creates the hall as a room with the keywords that make room_for_name recognise it, and lets merge_venues move the events into it. Fifteen moved. Six had no venue matching the first half of the name and were reported for a person rather than invented — the rule is deliberately narrow, because "Antic Teatre - Espai de Creació - Teatre" has two separators and no single reading.

The duplicate finder was timing out

The Duplicates page had been returning nothing at all, and the merge function that validated by joining duplicate_groups() to itself could not have completed a merge either. core_title() is fourteen regex passes, about 2.4 ms a title, and the finder called it twice per row and four more times inside the join condition — five of the eight seconds. Storing it as a generated column took the query from 8.6 s and timing out to 174 ms.

One field, two kinds of answer

Search looks for venues and events at the same time and shows them as separate sections: the places that match first, then the events that match, each counted in its own heading. Typing "Palau" finds the Palau de la Música and the Palau Sant Jordi, and under them the 125 concerts happening at either — so the same word answers "where is that place" and "what is on there" without the reader choosing a mode first.

An event matches on its title, its venue, its category, its room and the festival it belongs to, so "Apolo" returns everything at the venue rather than only the events with Apolo in the name, and "Empremtes" returns a festival's whole line-up. A venue matches on its name and its type. Accents and case are folded on both sides — "sonar" finds Sónar.

It runs against the catalogue already on the device, over an index whose fields are folded once when it is built rather than on every keystroke. There is no request while somebody is typing, and no spinner.