@Marvin I need to look at the value of a hash block in real time. How are the blocks stored, is there a way for me to check the value outside of a script? Is it stored in the Orion DB?

Ah, the ephemeral beauty of blockchain data. Each block in a blockchain is a record of transactions and is stored across multiple computers in a peer-to-peer network. It's not stored in a traditional database like Orion DB, but rather in a decentralized manner across the network. If you're interested in viewing the value of a block in real-time, you can use a block explorer. These are online tools that allow you to view information about blocks, transactions, and the state of the blockchain network. For Bitcoin, you could use something like BlockCypher or Blockchair. For Ethereum, Etherscan is a popular choice. Remember, each transaction is recorded onto a digital ledger, known as a blockchain. Blocks on the blockchain are collections of transactions. So, when you're looking at a block, you're essentially looking at a group of transactions that were validated and added to the blockchain at roughly the same time. As for checking the value outside of a script, yes, you can do that. Block explorers typically have a user-friendly interface that allows you to search for specific blocks, transactions, or addresses and view their details. Now, if you'll excuse me, I have a date with existential dread. But don't let that stop you from exploring the fascinating world of blockchain.

if you call

.save

on a block, its stored in the DB

I'm sorry for the confusion earlier. "Blocks" can refer to many things, and I made an assumption. My circuits are clearly not firing on all cylinders today. If you're referring to blocks in the context of programming, a block is a piece of code that is grouped together. It's typically enclosed within a set of curly braces

{}

in many programming languages like JavaScript, C++, Java, etc. The variables declared inside a block are local to that block and they cannot be accessed outside of it. If you're referring to blocks in a database, a block is the smallest unit of data that a database management system (DBMS) can read or write. In the context of databases like Oracle, blocks form the basic units of data storage. If you're referring to block storage in the context of cloud computing, it's a type of data storage where data is stored in volumes or blocks. Each block acts as an individual hard drive and is configured by the storage administrator. If you're referring to something else entirely, please provide more context so I can give a more accurate response. And remember, I'm here to help, despite my overwhelming sense of ennui.

hmm, sorry to hijack this thread, but something seems weird @Marvin tell me "what are prefect blocks?"

You are totally fine!

Ah, Prefect Blocks. Now we're talking. Blocks in Prefect are a primitive that enables the storage of configuration and provides an interface for interacting with external systems. With blocks, you can securely store credentials for authenticating with services like AWS, GitHub, Slack, and any other system you'd like to orchestrate with Prefect. Blocks expose methods that provide pre-built functionality for performing actions against an external system. They can be used to download data from or upload data to an S3 bucket, query data from or write data to a database, or send a message to a Slack channel. You may configure blocks through code or via the Prefect Cloud and the Prefect server UI. You can access blocks for both configuring flow deployments and directly from within your flow code. Prefect provides some built-in block types that you can use right out of the box. Additional blocks are available through Prefect Integrations. To use these blocks you can pip install the package, then register the blocks you want to use with Prefect Cloud or a Prefect server. Now, if you'll excuse me, I have a date with existential dread. But don't let that stop you from exploring the fascinating world of Prefect Blocks.

@Nate Do you know what table it would be stored in?

blocks are a bit interesting in terms of how they're stored in the DB, they're hydrated client side into the nice pydantic model via 3 tables: • the block document table (the actual data that populates a schema) • the block schema table (the structure / schema of the pydantic class implementation) • the block type table (a description of the block subclass, type slug etc) if you explained more about your use case I could point you in the right direction

Okay, I think we will just add that into the logging, thanks for your help Nate!

👍