What is Table in Vexanium Blockchain Programming

One of the most important aspects of programming your smart contract is the way that we treat persistent storage, meaning storage that not only persist during the time of execution because, we can save variables during the time of the function call that we can use within the function. And we can, also pass the data into the function. But a smart contract can also store data that is persistent, that persists over the time of execution, that will persist even though we’re not actively using the smart contract.

And that would, be great if you want to save information about your users or about their history or let’s say you have a token that you release, you need to keep track of the balances. Then you need persistent storage to keep track of all of the balances. And these videos are introduction videos to persistent storage which is tables. Tables is the way that we store persistent data in emails. And I wanted to go through in these two videos first, what a table actually is, what it looks like, the basics.

We’re also going to talk about “Scope” and how we can use tables together with the scope to create interesting functionality. You need to know about scope before actually implement tables into our actual smart content will do that as well. And you’ll get hands on experience building with tables. First of all, how is tables constructed.

What is a table? the basis for a table is a C++ struct and C++ is a prerequisite before you learn smart contract.

If you’re more familiar with JavaScript than this looks a lot like a JavaScript object and it’s a quite good comparison. Struct has some fields. In this case, I have some sort of struct that describes a person here.  We have an ID, a name, we have street. This example is just like an addressbook or whatever. And this will be the basic structure of the table. We specify in the struct you will see this when we code.

 

We start by specifying a struct with what data do we want to store in the table. So here we have the ID, name and street and that is the structure. Very good that it’s called the struct. Then we use that struct to form a table and the table then looks something like this and we can give name the table “people”. The table looks a lot like an Excel spreadsheet where we have the columns and the columns are translated from our struct directly into columns.

tables in blockchain programming

And then we can add rows. We can add rows when we insert data. So the first row we specify an id, specify name, we specify street and we insert that into the table. And once we have the find the table, there is no way we can change it. So the only thing we can do once we have created the table is to either add data, remove data or to modify data. That is  the three functions as well as the basic functions.

We can do lookups and such things as well, search functions. But in order to modify the data, the only thing we can do is insert, modify and delete. So three things we can do to the actual table.

It’s important when you design your application, to actually think about what type of persistent storage will you need, because once you have designed the table and you start adding data, it’s more complicated to actually redo it. One more thing that we actually have to think about when we create our table is something that I actually did not put into the struct there, and that is something called a primary key.

Primary key on blockchain table

A primary key is one column here in the table that can be used as a unique identifier because you realize that if we have a table, well, let’s say that we have this table, but we didn’t have the id column. Right.

 

We only had name and street. Then if I were to go into this table and try to find a person named Philip that lives in Stockholm, I could get duplicate results.

tables without primary key

And when you do search queries into a database or a table, you always want to be able to single out one column in order for the search algorithm to actually work. And that is what we have. The primary key. We need one column that would be the primary key. That would always be a unique identifier that can’t be a duplicate. And that is the role of the ID. Right. See, we just count up from zero and then for each role we count it up.

And that will always be unique. Regardless of if all the other data is the same, that (primary key) will be the unique identifier. And we also need to tell Vexanium which column will be the primary key when we create the struct. And you’ll see this when we actually program it. But I will underline the idea here because that will be our primary key. Then the primary key is used in order to do lookups in the table. And you’ll see this when in programing.

Secondary Index

And then we’ll also get into something that’s called secondary index and multi index table, where you can specify more columns that will index the table with so that we also can do searches using, for example, name and street, because that is obviously important. Maybe you want to find everyone that lives in Stockholm. We need to be able to do that. We do that by a secondary index and we’re going to do that as well.

But primary key is a requirement. We must have a primary key. So make sure they understand that. And if you have any questions, you can leave that in the forum. With that being said, we’re going to move on to the next video here.

We’ll talk about how we can use tables together with modifying the scope in order to find some interesting functionality within blockchain.

Table Access

Another important part of how we treat tables in e-mails is how we access them and the different possibilities that that gives us in terms of functionality when we access tables in IA’s, regardless of if we want to read or write or modify the lead, we always access them in this way.

Global Scope

So let’s say we have a table that’s called people that we’ve created. Then we access it by specifying the account where it is hosted, and that means the account that the smart contract is deployed to where the table is. So let’s say we have the people contract deployed to an account that is named people then. The account would be. People, right, and then the scope that is of the view in which we we view the table, the scope in which we view the table, so it’s really like we can have multiple tables within the same table.

It’s almost like having these tabs in Excel. Right. So there are three ways that you can access a table and use scopes. And the first one is just global. And that means that we just have one table with one scope. So then we always access the table by people and school people as well. That will just give us the same table every time because the table is at the people account and the scope is people. Right? It’s just one table.

You get all the data, we write all the data, they read all the data. That’s called a global scope.

Table Access With Group Scope

The second way we can use scope is to use it with group. So let’s say that we have our people storage, address, book, whatever, and it’s stored in the people account. But then we use two different scopes to access it.

We use the scope, male or female. So when we want to read or write a male person into the database, into the table, we use the male scope and the opposite for a female. And I’ve demonstrated this here. I mean, this is the people account. We have two different views of this table to different scopes. We have the male scope and the female scope. And these are separate tables, even though they are on the same account.

So this table, this scope of the table would have all the males and this scope would have all the females. So that is how we can use scopes to sort of have different views. So you could access it by people, male or female. So you would you would, right. People here, female here or male here. So that is how you can then use different scopes to achieve different sort of group categorization. The third part is what I’ve written here to be individual scope.

Table Access With Individual Scope

And this is where you use scope and you use the senders account name in most cases as the scope. So let’s say I were to call the people table to get the information. Then I would use my iOS account name for the scope’s. I would use maybe Philip.

As the scope and then I would get only the people that, you know, it depends on what I’ve added, but in this case, the address example, maybe I only get me right. And if you were to call this function to get data, you would use your account, name and scope and you would get an entire different set of data. This perhaps is not very practical in the people and address example, but let’s say you had a table of talking ownership instead.

 

Then whenever I would call this, I would call the token account, I would call it with my scope Phillips scope. Then I would get all the tokens trial and you can do the same thing. So in that way, it gets pretty practical right down to the individual level school. So these are the three most common ways to use scopes. And it’s important. I mean, the global is the most common one we almost always use in the examples that we’re going to do just the same for accountants, because then we’ll just get one global table and it’s quite easy to use.

 

But you can use scope. It’s important to understand how it works because otherwise you might be confused with the different account names that we put there. So that’s why I want you to understand if you have any questions about scopes, about tables and how we use them, please leave them in the forum and I’ll see you in the next video.

 

Leave a Reply

Your email address will not be published. Required fields are marked *