Quick recap from PART-1

Before we explore how to use InterPlanetary Linked Data (IPLD) for document store based interface, have you read the PART 1 of this series yet? Here’s the link to PART 1 in case you want to catch up.

TLDR: In PART 1, we explored the basic concepts of IPLD, how it is used in the InterPlanetary File System (IPFS). We also scratched the surface by building a key-value based database interface on IPFS using IPLD.

What We Will Learn from PART-2? 🤔

In PART 2 of the series, we will directly dive into the coding and see how to enhance the functionality to build document storage (similar to MongoDB and other document databases).

If you get stuck in any part or have any queries/doubts, then feel free to reach us out on our discord channel.

Here is the final shown down 😎

Changing the Data Structures 🛠

In contrast to PART 1, our data structure will be a structure that will be further mapped by a string type key. Each document entry we store is of the following format. This is very similar to how you develop schemas:

As shown above, we have defined SampleStruct, which defines three fields representing an employee's data record. This means we can contain each employee's ID, Name and corresponding Salary amount in the structure's instances.

Changing the Way We Track Entries

Further, we need to manage this relationship in mapping on its own ID to facilitate Read or Lookup operations for each employee record. Hence, we update the current mapping as follows:

Taking User Input 👨‍💻👩‍💻

Now, we can ask users to enter the values for all the three fields as defined in the SampleStruct. Once we have the value for all the three fields (namely ID, Name and Salary), we can initiate an object/instance based on the definition and assign the received values as follows:

The Document-Storage Magic 🔮✨

Once the object is created and the captured values are assigned, we can map the same object in the mapping by its own ID value. Once the mapping is updated, we can now write it to the Merkle DAG as follows:

If you are scratching your heading thinking what does a DAG means & what does DagPut function do, then we recommend going through the PART 1 of the series.

We have now successfully written the mapping to the IPLD DAG and a CID may be returned. Yay🎉🎉

A Change in Reading DAGs for Entries

Now, we must update our code to read the document from the mapping. In contrast to PART 1, the read operation will not be returning a mere single-value. It will be returning the whole JSON document as defined in the schema. Hence, we update the getter function by changing the return type as follows:

Now, let us call this getter/read function in main.go as follows:

As shown above, the GetDocument is passed with the ID value which was earlier entered by the user. Based on the ID value, the corresponding document is returned from the mapping.
Once the document is returned, we can parse it as required and print the Salary of the inquired employee.

Conclusion

We hope you had fun learning how to enhance the code to support document storage. Go crazy and build your own decentralized document database.

If you get stuck in any part or have any queries/doubts, then feel free to reach us out on our discord channel.

And here is the link to the full implementation of the code on GitHub.