Morning

Morning

sits down

sips coffee

Good morning heap

did everyone have a nice weekend

Hell yeah.

Broke my phone

that's a good first step to faking your death

Someone wants me to pull data out of Mongo so I might actually have to do that

at least it's only going out

Unfortunately that's the worst direction as far as mongo is concerned

why?

1. the syntax is bad 2. everything is JSON 3. S-L-O-W

Brazil is just three levels above Korea

4-0 in the first 35 min

@bbaird Did you try sharding it across 8 servers first?...maybe that'll help the performance?

Speaking of NoSQL, we're probably going to start playing with Azure Blob Storage and Azure Table Storage for some use cases. Should be interesting...but at least it's not MongoDB.

I call that type of storage CSV+ since it's basically text files with a method to read/partition included

ExpensiveCSV++

lol true

They want to use it for storing images for an OCR process. 🤷‍♂️

C$V

Well, that's slightly different and probably more in line with a decent use case.

@ypercubeᵀᴹ first game they show their superiority though

Yea, Blob Storage for the raw file, Azure Functions to process it leveraging built-in OCR services in Azure, and Table Storage as a staging area (in case our API is down) until it's pushed through our API to our local SQL Server database.

We'll see how it goes, I'm not directly involved, more so just a bystander 👀

Seems like too many steps

@J.D. maybe the table storage seems like overkill

Yea I suggested we probably don't need the Azure Table storage and can just hit the API directly from the Azure Function, to simplify a little. Who cares if the API is down randomly in that moment, the OCR Azure Function will just re-process it anyway.

@Lamak yup exactly.

@J.D. also, you can mostly query that blob storage directly (for the not OCR part) if you use it as a data lake

We're no where near the volume that the minimum service tiers are for these services, that we can afford to re-run things once in a blue moon.

@J.D. of course you do, it's just a configuration for the blob storage account that adds mostly zero to the cost

@Lamak Yea, they probably are going to just purely OCR the files, and then delete them from the Blob when done.

ah I see

The goal is basically as a way to queue files to be processed from an end user facing application, without locking up the app while the OCR process is running, and to just generally decouple the responsibility of the app from the OCR process (e.g. if the app crashes before the process finished, etc).

sounds like a plan...except the table storage part ;)

Yea you and me are on the same page. 🤙

@JoshDarnell Have you done the AoC day 5? Kusto can't use loops or recursion and I have trouble coming up with a set-based solution

@Zikato I did it in C#, using loops and stacks. Definitely sounds tricky to do set based without recursion.