67 bytes raw

i=1:1:100 $s(i#15=0:"FizzBuzz",i#3=0:"Fizz",i#5=0:"Buzz",1:i),!

Fantastic! Thank you for looking at the speed, those changes do help. I guess I thought metadata was retrieved on a row basis, but no!

Yes, as much as I'd like to use that method, my queries can get very complicated and it never worked the way I needed it to, and I didn't want to spend the majority of my time working on query syntax. There's a lot of people who write normal queries that I work with as well, who would need to update a ton of sql!

Something to note, if you delete the repo, the pull request will show up as "unknown repository"

and any history attached to that repo will be lost. Also any references to it will of course be broken. But deleting the branch is encouraged by github and won't break any references. For me, I don't like broken links and references, but of course there's the argument of wanting a clean profile instead of 1000 old forked repos :)

It's serving static files. I like that it's easy to manipulate how the server sends CSP, such as manipulating custom headers or session information right out the gate. But I also have a lot of non-csp resources that are served that I'd like to know more about how the server handles them. Do they go through the CSP logic? How are they served from server to client?

Thanks for the insight, there must be some nuance with this table's integer fields. I linked another table and I can query an integer field with a large number, not just id, and they all have the same property definitions. This must be a problem specifically with the one table, although I wonder why id works fine on another linked table if it's projected through xDBC as integer.

I prefer objects as well especially when the amount of optionals are getting too large. I think when you start adding more and more optionals then it's time for a rethinking of what the function is really trying to accomplish.