If last week felt like a wake-up call, then this week felt like learning how to walk all over again. I spent most of it digging into things I thought I already understood — only to discover that the more I explored, the more questions I had. It was challenging, uncomfortable at times, but also strangely motivating.
Looking Closer Than Before
I started by revisiting the whole getList flow: filters, sorting, indexes, and how find() and query() actually behaves. I traced every part that relied on currentPartition and logged the real network calls just to see how CouchDB responded behind the scenes.
That led me into discovering the limitations of Mango queries, partitions, and PouchDB’s missing helpers. It wasn’t the most exciting work, but it taught me a lot about how the system really works.
Falling Into Map/Reduce
Since Mango wasn’t enough, I explored Map/Reduce and cdb.query():
- testing different view-query formats
- checking whether
createIndex()views could be reused - studying how server-side design docs handle sorting and counts
Most experiments failed, but the failures were useful. I learned that Mango’s indexes can’t be reused, partitioned databases behave differently, and some tools simply aren’t published.
Choosing a Better Direction
Once the limitations were clear, I planned a cleaner approach: remove the global currentPartition, pass context explicitly, and rely on proper design docs. I prepared the proposal, discussed it with my supervisor, and kept sorting KIV for further refinement.
Reflections & Insights
- Understanding requires patience, not speed.
- Failures teach more than quick wins.
- Clean design matters even if no one sees it.
- Reliability becomes real when you’re supporting a live event.
What’s Coming Up
Next week, I’ll refine the sorting and counting logic and continue improving test coverage. Slow progress, but meaningful progress.
0 Comments