Diving into Ledger Databases and Reporting Setup
Today was one of those days where it felt like we were making progress, even if it wasn’t always obvious. The big focus for the team has been digging into ledger databases. If you're not familiar, ledger databases are like supercharged digital record-keepers—they make sure that once you write something down, it can’t be changed without leaving a trail. Think of it like a digital notebook where every change you make is logged and timestamped, perfect for making sure we’re keeping up with all the rules and regulations we’ve got to follow. Since we needed something like this for audit purposes anyway, we figured, why not use it as the foundation for our reporting? Two birds, one stone—keeping our compliance folks happy while also ensuring our reports are rock solid.
The Ledger Database Maze
We’ve been doing a lot of digging into ledger databases, and it’s been a bit of a ride. We’ve messed around with Amazon QLDB before—Amazon’s Quantum Ledger Database. It’s a pretty solid option if you need something that’s managed and easy to use, but there’s a catch: Amazon’s pulling the plug on it next summer. That was a bummer because it checked a lot of boxes for us. Then we gave Azure SQL’s ledger feature a try. Now, Azure SQL is Microsoft's cloud database service, and adding a ledger to it is supposed to add that same tamper-proofing. But, let me tell you, getting that thing set up felt like trying to read a book in a foreign language. The docs were all over the place, and we never did get the data to show up in the storage bucket like it was supposed to. We didn't even bother with Hyperledger this time around—if you’re not familiar, Hyperledger is basically a toolkit for building your own blockchain networks. It’s powerful, but honestly, way too complicated for what we need right now. We’re just trying to get some straightforward audit trails and reporting, not reinvent the blockchain.
Switching from PUT to PATCH
Another thing we’ve been hashing out is switching our lot updates from using PUT to PATCH. Right now, PUT is the method we’re using to update a lot’s details from the frontend (that’s the part of the app the users see and interact with) to the backend (where all the data and business logic lives). The problem with PUT is that it’s a bit like taking a sledgehammer to the whole data record—it replaces everything. If there’s even the tiniest hiccup—like a slow internet connection or a bug in the code—you could end up losing data. PATCH, on the other hand, is more like a scalpel—it only updates the specific bits that need changing. Much safer. We’re still working on swapping it over in the code, but it shouldn’t be a huge lift. It’s mostly a matter of switching out the verbs and testing to make sure nothing breaks. It feels like the right move, especially with how critical some of this data is. You don’t want to wake up to find out half your data went missing because of a flaky network connection.
Getting the Reporting Tables in Shape
On the reporting side, we’ve made some strides, even if it doesn’t always feel like it. We got a temporary "fact" table set up in our PostgreSQL database (that’s our main storage engine for structured data). For those not knee-deep in database lingo, a "fact" table is where we keep all the key metrics for analysis, like the number of plants in each lot or the different strains we’re growing. We had some frontend bugs that were throwing us off track for a bit—nothing like seeing data jump around to make you feel like you’re losing your mind—but we sorted those out, and now things are looking more stable. Right now, we’re sticking with a simple structure for the reporting table—a flat list with all the data points in one place. It’s not the most optimized, but it gets the job done. Down the line, we might need to refactor to make it more efficient, but for now, it’s more important to get something working and go from there.
Challenges, Breaks, and Getting Back on Track
Today had its fair share of curveballs. Some of us didn’t get much sleep last night, which definitely didn’t help. It’s tough to get your head straight when you’re running on fumes. When things started getting too foggy, we decided to take breaks—some of us went for a drive, others took a walk. Sometimes stepping away is the best thing you can do. It’s amazing what a little fresh air can do for your perspective. After that, we came back with a bit more clarity and were able to push through some of the blockers.
Keeping the Frontend and Backend in Sync
We haven’t made any major changes to how the frontend talks to the backend, but it’s clear we need to be more careful with data integrity. When you’ve got multiple API calls firing off, especially if they’re happening in quick succession, you need to make sure the data stays clean and accurate. An API call is basically the frontend saying, "Hey, backend, here’s some data," or "Give me this data." We haven’t put anything concrete in place yet, but we’re thinking about adding some sort of row locking or transaction handling on the database side. This would help make sure everything happens in the right order and nothing gets messed up along the way.
What’s Next?
Looking ahead, the plan is to keep chipping away at the reporting setup. We want to make sure all the attributes are properly mapped and saving to the backend without any hiccups. It’s not the most glamorous work, but it’s gotta be done. On the horizon, we’re also thinking about the bigger picture—maybe finding some sponsorship or funding. Keeping the lights on isn’t free, and if we could get some backing, we could really accelerate our development, especially with those sensors we’re building.
Wrapping Up
So yeah, today was a mix—some good progress, some bumps in the road. But that’s pretty much par for the course when you’re building something from the ground up. The important thing is that we’re learning and adapting as we go. Here’s hoping tomorrow brings fewer surprises and a little more progress.