LKDB (Personal DBMS)

A REPORT

Submitted by

Lakshya (RA2311003030206)

Under the guidance of

Ms. Bhawna upadhayay

(Department of Computer Science & Engineering)

in partial fulfilment for the award of the degree

of

BACHELOR OF TECHNOLOGY
in

COMPUTER SCIENCE & ENGINEERING

of

FACULTY OF ENGINEERING AND TECHNOLOGY

SRM INSTITUTE OF SCIENCE & TECHNOLOGY, NCR CAMPUS

JULY 2025

1|Page
 SRM INSTITUTE OF SCIENCE &
TECHNOLOGY
(Under Section 3 of UGC Act, 1956)

BONAFIDE CERTIFICATE

Certified that this report titled “LKDB (Personal DBMS)” is the bonafide work
of “Lakshya (RA2311003030206)”, who carried out this work under my
supervision. Certified further, that to the best of my knowledge the work
reported herein does not form any other report on the basis of which a degree
or award was conferred on an earlier occasion on this or any other candidate.

Signature
Signature
Ms. Bhawna upadhayay
Dr. Avneesh Vashistha
Assistant Professor
HEAD OF THE DEPARTMENT
Dept. of Computer Sciene &
Dept. of Computer Science &
Engineering
Engineering

2|Page
 ACKNOWLEDGEMENT

I would like to express my gratitude to my project supervisor, Ms. Bhawna

Upadhayay for her guidance and support. Special thanks to the members of our
team for their dedication and collaboration. Lastly, I’d thank our families and
friends for their encouragement throughout this journey. This project benefited
greatly from the collective effort and support of everyone involved.

3|Page
 Team Members and Their Roles

Lakshya(RA2311003030206)
I was involved in the GUI designing and in conceptualization of the basic framework behind
our project. I was in-charge of the Server-Client communication and Exception Handling. I
worked out the event handling and the general feel of our app. I was responsible for the
Server-Client programming and incorporating a multi-user environment for our app.

4|Page
Abstract:
The Language-Friendly Key-Value Pair Database (LKDB) tackles the increasing complexity
of modern software development, where applications often leverage a multitude of
programming languages to optimize specific functionalities. Traditional database systems,
while powerful, can introduce significant hurdles when integrating with such diverse language
ecosystems. These challenges often stem from intricate data type mappings,
serialization/deserialization complexities, and the need for language-specific drivers and query
languages. The Language-Friendly Key-Value Pair Database (LKDB) emerges as a solution by
prioritizing seamless data interaction across various programming environments.

At its core, LKDB is a lightweight and highly efficient key-value store engineered with
language interoperability as a fundamental design principle. Unlike conventional databases that
might impose specific data models or query paradigms, LKDB adopts a simplified key-value
structure, offering a flexible foundation for storing and retrieving data of various formats. The
"language-friendly" aspect is achieved through the strategic selection of a universally accessible
data serialization format. By employing widely adopted standards such as JSON (JavaScript
Object Notation) or Protocol Buffers, LKDB ensures that data stored within it can be easily
understood and processed by a wide range of programming languages without requiring
extensive custom parsing or conversion routines.

To further enhance its usability across different language environments, LKDB is designed to
offer intuitive and consistent access mechanisms. This can be achieved through the
development of lightweight and well-documented client libraries or APIs tailored for popular
programming languages like Python, JavaScript, Java, Go, and others. These language-specific
interfaces abstract away the underlying communication protocols and data serialization details,
providing developers with a familiar and straightforward way to interact with the database.
Operations such as storing, retrieving, updating, and deleting data become simple function calls
or method invocations within their chosen language.

The adoption of LKDB offers several key advantages in polyglot application architectures. It
significantly reduces the data handling overhead associated with cross-language
communication, allowing developers to focus on application logic rather than wrestling with
data format conversions. Furthermore, it promotes seamless data sharing and consistency across
different components of a system, regardless of the programming language in which they are
implemented. This streamlined data exchange can lead to increased developer productivity,
faster development cycles, and more maintainable and scalable applications.

This project delves into the architectural design of LKDB, exploring the choices behind its data
model, serialization strategy, and API design. It also examines the implementation details of
the core storage engine and the development of the language-specific client libraries. Finally,
the project includes a performance evaluation of LKDB, analyzing its efficiency in terms of
read/write operations and its ability to handle concurrent access from multiple language
environments. The findings will highlight LKDB's potential as a valuable tool for simplifying
data management in modern, multi-language software systems.

5|Page
Table of Contents:

CONTENTS PAGE

1. INTRODUCTCION 7

2. LITERATURE REVIEW 7

3. IMPLEMENTATION 8

4. CODE EXPLANATION 9

5. TESTING 16

6. RESULTS 17

7. DISCUSSION 20

8. CONCLUSION 20

9. REFERENCES 23

6|Page
Introduction:
Introducing the Language-Friendly Key-Value Pair Database (LKDB), a novel approach to data
management designed to address the growing need for seamless interoperability in modern,
polyglot application architectures. Traditional database systems often present integration
challenges when interacting with diverse programming languages, leading to complexities in
data serialization and language-specific handling. LKDB tackles this issue head-on by
employing a universally accessible data serialization format and providing intuitive access
mechanisms through language-specific APIs or client libraries. This design philosophy aims to
simplify data storage and retrieval across different programming environments, fostering
developer productivity and enabling straightforward data sharing within complex, multi-
language systems. By prioritizing language neutrality, LKDB offers a lightweight and efficient
solution for managing data in a way that minimizes language-specific overhead and promotes
a more unified development experience.

Literature Review:
The concept of key-value pair databases has a rich history, with early examples like memcached
and Redis demonstrating their efficiency and scalability for caching and session management.
These systems excel at simple lookups and offer high performance for applications requiring
rapid data access. However, their focus has often been on performance within a specific
technological stack, sometimes leading to language-specific client libraries with varying levels
of abstraction and data handling.

The rise of microservices and polyglot programming has amplified the need for data storage
solutions that transcend language barriers. Existing relational database management systems
(RDBMS) like PostgreSQL and MySQL, while robust and feature-rich, can introduce
complexity when integrating with multiple languages due to differing data type mappings and
the need for Object-Relational Mapping (ORM) tools, which can add overhead and potential
inconsistencies. NoSQL databases, including document stores like MongoDB and columnar
databases like Cassandra, offer more flexible schemas but may still require language-specific
drivers and data serialization considerations.

Research in data serialization has explored various formats, each with its trade-offs. Binary
formats like Protocol Buffers and Apache Avro offer efficiency and schema evolution but can
be less human-readable and might require specific code generation for different languages.
Text-based formats like JSON and YAML are highly human-readable and widely supported
across programming languages, making them strong candidates for language-agnostic data
exchange. The choice of serialization format significantly impacts interoperability and the ease
of data consumption across different language environments.

The development of language-agnostic data access layers has been explored in various contexts.
RESTful APIs, for instance, provide a stateless interface for data interaction over HTTP,
enabling communication between services written in different languages. However, designing
and implementing efficient and consistent REST APIs for complex data operations can be
challenging. GraphQL offers a more flexible query language but still requires client-side
implementations in various languages.

Projects focusing on language interoperability in data management often explore middleware

solutions or standardized data exchange formats. Frameworks and libraries aimed at simplifying
cross-language communication, such as Apache Thrift and gRPC, provide mechanisms for
defining services and generating client and server code in multiple languages. However, these
17 | P a g e
solutions often operate at a higher level of abstraction than a fundamental data storage layer.

The Language-Friendly Key-Value Pair Database (LKDB) project builds upon this existing
body of work by directly integrating language interoperability into the core design of a key-
value store. By focusing on a simple key-value model and leveraging a universally supported
data serialization format, coupled with the provision of intuitive language-specific client
libraries, LKDB aims to offer a more streamlined and efficient solution for managing data in
polyglot environments compared to adapting traditional databases or relying solely on higher-
level communication protocols. This approach seeks to minimize the complexities associated
with cross-language data handling at the data storage level itself.

Implementation:
The Language-Friendly Key-Value Pair Database (LKDB) will begin with a core storage
engine. Initially, a straightforward file-based system will be used for portability, where key-
value pairs are stored, potentially with an in-memory index for faster lookups. For enhanced
performance and scalability, integration with embedded key-value stores like RocksDB or
LevelDB will be considered.

Data serialization will be a cornerstone, with JSON chosen for its universal support across
programming languages. Libraries within each target language (e.g., json in Python, JSON in
JavaScript) will handle the conversion to and from this format. The core engine will implement
fundamental CRUD operations: PUT (create/update), GET (read), and DELETE. Basic locking
mechanisms will ensure safe concurrent access.

Language-specific client libraries will provide an intuitive interface to LKDB. Consistent APIs
(e.g., put(key, value), get(key), delete(key)) will be developed for languages like Python,
JavaScript, Java, and Go, abstracting away storage interactions and serialization. These libraries
will handle the underlying details, offering a seamless experience for developers in their
respective languages.

Future enhancements may include a networked server component to allow distributed access,
along with a defined communication protocol. Thorough unit and integration testing will be
crucial to ensure reliability, and comprehensive documentation will guide developers. Initial
focus will be on basic data types easily representable in JSON. Scalability and performance
will be addressed iteratively, potentially through the adoption of embedded databases or a
networked architecture. This phased implementation prioritizes cross-language usability from
the outset.

Code Explanation:
Okay, let's outline a potential implementation plan for the Language-Friendly Key-Value Pair
Database (LKDB). This will cover the core components and considerations.

I. Core Storage Engine:

• Choice of Underlying Storage:

o For simplicity and portability, we could start with a file-based storage

mechanism. Each key-value pair could be stored as a separate file or within a
18 | P a g e
 structured file format.

o Alternatively, for better performance and scalability, consider using an

embedded key-value store like RocksDB or LevelDB. These offer robust
features like efficient data structures (LSM trees), persistence, and concurrency
control.

• Data Serialization:

o Implement serialization and deserialization using a chosen language-agnostic

format. JSON is a strong initial candidate due to its simplicity and wide support
across languages. Libraries like json in Python, [Link] and [Link]
in JavaScript, [Link] in Java, etc., can be used.

o Consider Protocol Buffers as a more efficient and schema-driven alternative for

later stages, requiring libraries like protobuf in various languages.

• Basic Operations: Implement the fundamental CRUD (Create, Read, Update, Delete)
operations:

o PUT (Create/Update): Takes a key and a value (which will be serialized) and
stores it in the underlying storage.

o GET (Read): Takes a key, retrieves the serialized value from storage, and
deserializes it.

o DELETE: Takes a key and removes the corresponding entry from storage.

• Indexing (Optional but Recommended):

o For efficient lookups, especially with a file-based approach, maintain an in-

memory index that maps keys to their storage locations (e.g., file path and
offset). This index would need to be updated on PUT and DELETE operations.

o Embedded databases like RocksDB and LevelDB handle indexing internally.

• Concurrency Control:

o Implement basic locking mechanisms (e.g., file-level locks for file-based storage
or the concurrency control provided by the embedded database) to handle
concurrent access from multiple clients or threads.

II. Language-Specific Client Libraries/APIs:

• Common API Design: Define a consistent and intuitive API across all client libraries.
This could involve functions like put(key, value), get(key), and delete(key).

• Implementation for Key Languages:

o Python: Create a Python library (e.g., using standard library features for file I/O
and the json module).

o JavaScript: Develop a JavaScript client (for [Link] and potentially browser

environments) using built-in features or libraries like node-fs (for file I/O in
19 | P a g e
 [Link]) and the JSON object.

o Java: Build a Java library using standard Java I/O and a JSON processing library
like Jackson or Gson.

o Go: Implement a Go package using standard Go I/O and the encoding/json

package.

o (Extend to other target languages as needed)

• Abstraction Layer: The client libraries should abstract away the underlying
communication with the core storage (whether it's direct file access or communication
with a server if you decide to network the LKDB later) and handle the
serialization/deserialization transparently.

III. Potential Networked Version (Future Enhancement):

• Server Component: Develop a server application that exposes the LKDB functionality
over a network protocol (e.g., TCP or HTTP).

• Communication Protocol: Define a simple protocol for client-server interaction,

potentially using a text-based format for requests and responses (e.g., custom commands
over TCP or RESTful HTTP endpoints).

• Client Communication: The language-specific client libraries would then communicate

with the server instead of directly interacting with the storage.

IV. Testing and Documentation:

• Unit Tests: Write comprehensive unit tests for the core storage engine and each
language-specific client library to ensure correctness and reliability.

• Integration Tests: Develop integration tests to verify the interaction between different
language clients and the storage engine (or server).

• Documentation: Provide clear and concise documentation for the API of each client
library, including examples of how to use the basic operations. Document the overall
architecture and design choices of LKDB.

V. Considerations:

• Error Handling: Implement robust error handling in both the core storage and the client
libraries.

• Data Types: Initially, focus on handling basic data types that can be easily serialized
into JSON (strings, numbers, booleans, lists, dictionaries). Consider how to handle more
complex or language-specific data types in the future.

• Scalability and Performance: For the initial file-based approach, scalability will be
limited. If performance and scalability are critical early on, using an embedded key-
value store is recommended. A networked version would also be necessary for
distributed deployments.

This implementation plan provides a starting point. The specific technologies and approaches
110 | P a g
e
can be adjusted based on your priorities and the scope of the project. Starting with a simple,
file-based storage and JSON serialization with client libraries for a couple of key languages
would be a good way to begin.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "lkdb.h"

#define MAX_INPUT_SIZE 256

struct lkdb *get_db_by_name(struct lkdb **dbs, int db_count, char *db_name)

{
for (int i = 0; i < db_count; i++)
{
if (dbs[i] && dbs[i]->dbname && strcmp(dbs[i]->dbname, db_name) == 0)
{
return dbs[i];
}
}
return NULL;
}

int main()
{
struct lkdb *dbs[10]; // Array to store multiple databases
int db_count = 0;
char input[MAX_INPUT_SIZE];
char command[MAX_INPUT_SIZE];
char db_name[MAX_INPUT_SIZE];
char key_name[MAX_INPUT_SIZE];
char value_name[MAX_INPUT_SIZE];

printf("Bhai, kya karna hai?\n");

while (1)
{
printf("> ");
fgets(input, MAX_INPUT_SIZE, stdin);
input[strcspn(input, "\n")] = 0; // Remove newline

if (sscanf(input, "bhai ek db bnao, jiska naam ho, %s", db_name) == 1)

{

dbs[db_count] = bhai_ek_db_bnao(db_name);
if (dbs[db_count] != NULL)
{
printf("Bhai, %s database ban gaya!\n", db_name);
db_count++;
}
else
{
printf("Bhai, database banane mein dikkat hui.\n");
}
}
else if (sscanf(input, "bhai ye, %s mein, %s mein, yeh %s, rakhna", db_name, key_name, value_name) == 3)
{
struct lkdb *db = get_db_by_name(dbs, db_count, db_name);
if (db)
{
bhai_ye_value_rakhna(db, key_name, value_name);
printf("Bhai, %s mein %s: %s rakh diya!\n", db_name, key_name, value_name);
111 | P a g
e
 }
else
{
printf("Bhai, %s database nahi mila.\n", db_name);
}
}

else if (sscanf(input, "bhai ye, %s mein, %s delete krna", db_name, key_name) == 2)

{
struct lkdb *db = get_db_by_name(dbs, db_count, db_name);
if (db)
{
bhai_ye_value_delete_krna(db, key_name);
printf("Bhai, %s mein %s delete ho gaya!\n", db_name, key_name);
}
else
{
printf("Bhai, %s database nahi mila.\n", db_name);
}
}
else if (sscanf(input, "bhai ye, %s mein, %s dekhna", db_name, key_name) == 2)
{
struct lkdb *db = get_db_by_name(dbs, db_count, db_name);
if (db)
{
struct lkdb_lookup_result *result = bhai_ye_value_dekhna(db, key_name);
if (result)
{
printf("Bhai, %s mein %s ka value: %s\n", db_name, key_name, result->value);
bhai_ye_dekhna_aur_delete_krna(result);
}
else
{
printf("Bhai, %s mein %s nahi mila.\n", db_name, key_name);
}
}
else
{
printf("Bhai, %s database nahi mila.\n", db_name);
}
}
else if (sscanf(input, "bhai, %s mein, %s dekhna aur delete krna", db_name, key_name) == 2)
{
struct lkdb *db = get_db_by_name(dbs, db_count, db_name);
if (db)
{
struct lkdb_lookup_result *result = bhai_ye_value_dekhna(db, key_name);
if (result)
{
printf("Bhai, %s mein %s ka value: %s\n", db_name, key_name, result->value);
bhai_ye_value_delete_krna(db, key_name);
bhai_ye_dekhna_aur_delete_krna(result);
printf("Bhai, %s mein %s delete ho gaya!\n", db_name, key_name);
}
else
{
printf("Bhai, %s mein %s nahi mila.\n", db_name, key_name);
}
}
else
{
printf("Bhai, %s database nahi mila.\n", db_name);
112 | P a g
e
 }
}
else if (sscanf(input, "bhai, %s sahi toh hai an", db_name) == 1)
{
struct lkdb *db = get_db_by_name(dbs, db_count, db_name);
if (db)
{
int result = bhai_db_sahi_toh_hai_na(db);
printf("Bhai, %s sahi %s!\n", db_name, result == 0 ? "hai" : "nahi hai");
}
else
{
printf("Bhai, %s database nahi mila.\n", db_name);
}
}
else if (sscanf(input, "bhai, %s ka size btana", db_name) == 1)
{
struct lkdb *db = get_db_by_name(dbs, db_count, db_name);
if (db)
{
int size = bhai_iska_size_btana(db);
printf("Bhai, %s ka size: %d\n", db_name, size);
}
else
{
printf("Bhai, %s database nahi mila.\n", db_name);
}
}
else if (sscanf(input, "bhai, %s ka inorder print krna", db_name) == 1)
{
struct lkdb *db = get_db_by_name(dbs, db_count, db_name);
if (db)
{
bhai_inorder_print_krna(db);
}
else
{
printf("Bhai, %s database nahi mila.\n", db_name);
}
}
else if (sscanf(input, "bhai, %s save kr do", db_name) == 1)
{
struct lkdb *db = get_db_by_name(dbs, db_count, db_name);
if (db)
{
bhai_db_save_kr_do(db);
printf("Bhai, %s save ho gaya!\n", db_name);
}
else
{
printf("Bhai, %s database nahi mila.\n", db_name);
}
}
else if (strcmp(input, "exit") == 0)
{
break;
}
else if (sscanf(input, "bhai ye, %s, delete kr do", db_name) == 1)
{
struct lkdb *db = get_db_by_name(dbs, db_count, db_name);
if (db)
{
113 | P a g
e
 bhai_ye_db_delete_kr_do(db);
for (int i = 0; i < db_count; i++)
{
if (dbs[i] == db)
{
dbs[i] = NULL;
break;
}
}
printf("Bhai, %s database delete ho gaya!\n", db_name);
}
else
{
printf("Bhai, %s database nahi mila.\n", db_name);
}
}
else
{
printf("Bhai, samajh nahi aaya. Kya bol rahe hai?\n");
}
}

// Cleanup
for (int i = 0; i < db_count; i++)
{
if (dbs[i])
{
bhai_ye_db_delete_kr_do(dbs[i]);
}
}

return 0;
}

#include <errno.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "lkdb.h"

// Forwards
static int insert(lkdb_key_t *key, lkdb_value_t *value, struct node **rp);
static int remove_root(struct node **rp);
static int remove_(lkdb_key_t *key, struct node **rp);
static int truncate_transaction_file(struct lkdb *avl);
static struct node *avl_search(lkdb_key_t *key, struct node *root);

//
// CRC32
//

uint32_t crc32_table[256];

void generate_CRC32_table()
{
uint32_t c;
for (int i = 0; i < 256; i++)
{
c = i;
for (int j = 0; j < 8; j++)
{
114 | P a g
e
 if (c & 1)
{
c = 0xEDB88320L ^ (c >> 1);
}
else
{
c = c >> 1;
}
}
crc32_table[i] = c;
}
}

uint32_t calc_CRC32(unsigned char *buf, int len, uint32_t prev_crc)

{
uint32_t crc = ~prev_crc;
while (len--)
{
crc = crc32_table[(crc ^ *buf++) & 0xFF] ^ (crc >> 8);
}
return crc ^ 0xFFFFFFFF;
}

uint32_t key_and_value_CRC32(lkdb_key_t *k, int klen, lkdb_value_t *v, int vlen)

{
uint32_t crc = 0;
crc = calc_CRC32(k, klen, crc);
crc = calc_CRC32(v, vlen, crc);
return crc;
}

//
// DISK IO
//

static int fwrite_str(uint8_t *s, FILE *file)

{
size_t itemsWritten = fwrite(s, strlen(s), 1, file);
if (itemsWritten != 1)
{
return -1;
}
return 1;
}

static int fwrite_uint32_t(uint32_t value, FILE *file)

{
size_t itemsWritten = fwrite(&value, sizeof(uint32_t), 1, file);
if (itemsWritten != 1)
{
return -11;
}
return 1;
}

static int fwrite_uint8_t(uint8_t value, FILE *file)

{
size_t itemsWritten = fwrite(&value, sizeof(uint8_t), 1, file);
if (itemsWritten != 1)
{
return -11;
}
115 | P a g
e
 return 1;
}

static int fread_str(uint8_t **v, uint32_t l, FILE *file)

{
if (l == 0)
return -1;
*v = malloc(l + 1);
size_t itemsRead = fread(*v, l, 1, file);
if (itemsRead != 1)
{
free(*v);
*v = NULL;
return -1;
}
(*v)[l] = 0;
return 1;
}

static int fread_uint32_t(uint32_t *value, FILE *file)

{
size_t itemsRead = fread(value, sizeof(uint32_t), 1, file);
if (itemsRead != 1)
{
return -1;
}
return 1;
}

static int fread_uint8_t(uint8_t *value, FILE *file)

{
size_t itemsRead = fread(value, sizeof(uint8_t), 1, file);
if (itemsRead != 1)
{
return -1;
}
return 1;
}

static void save_tree_to_disk(struct node *root, FILE *file)

{
uint32_t l;
uint32_t magic = 0x42473000;
fwrite_uint32_t(magic, file);

if (root == NULL)
{
l = 0;
fwrite_uint32_t(l, file);
return;
}
l = strlen(root->key);
fwrite_uint32_t(l, file);
fwrite_str(root->key, file);
l = strlen(root->value);
fwrite_uint32_t(l, file);
fwrite_str(root->value, file);
fwrite_uint32_t(key_and_value_CRC32(root->key, strlen(root->key), root->value, strlen(root->value)), file);
fwrite_uint32_t((uint32_t)root->diff, file);
save_tree_to_disk(root->left, file);
save_tree_to_disk(root->right, file);
}
116 | P a g
e
int bhai_db_save_kr_do(struct lkdb *avl)
{
if (avl == NULL)
{
fprintf(stderr, "Error: Database pointer is NULL.\n");
return LKDB_DBNAME_IS_NULL;
}
if (avl->dbname == NULL)
{
fprintf(stderr, "Error: Database name is NULL.\n");
return LKDB_DBNAME_IS_NULL;
}
FILE *file = fopen(avl->dbname, "wb");
if (!file)
{
fprintf(stderr, "Error: Failed to open database file: %s\n", avl->dbname);
return LKDB_FAILED_TO_OPEN_DB_FILE;
}
save_tree_to_disk(avl->root, file);
if (fclose(file) != 0)
{
fprintf(stderr, "Error: Failed to close database file: %s\n", avl->dbname);
return LKDB_FAILED_TO_OPEN_DB_FILE;
}

if (truncate_transaction_file(avl) != LKDB_SUCCESS)
{
fprintf(stderr, "Error: failed to truncate transaction file.\n");
return LKDB_FAILED_TO_OPEN_DB_FILE;
}

return LKDB_SUCCESS;
}

static struct node *load_tree_from_disk(FILE *file)

{
uint32_t l, crc_calculated, crc_from_file;
uint8_t *v;

if (fread_uint32_t(&l, file) < 0 || l != 0x42473000)

return NULL;
if (fread_uint32_t(&l, file) < 0 || l == 0)
return NULL;
fread_str(&v, l, file);
struct node *new_node = malloc(sizeof *new_node);
if (!new_node)
{
perror("Failed to allocate memory for node");
exit(EXIT_FAILURE);
}
new_node->key = strdup(v);
free(v);
if (fread_uint32_t(&l, file) < 0)
return NULL;
fread_str(&v, l, file);
new_node->value = strdup(v);
free(v);
if (fread_uint32_t(&crc_from_file, file) < 0)
return NULL;
crc_calculated = key_and_value_CRC32(new_node->key, strlen(new_node->key), new_node->value,
strlen(new_node->value));
117 | P a g
e
 if (crc_calculated != crc_from_file)
return NULL;
if (fread_uint32_t(&new_node->diff, file) < 0)
return NULL;
new_node->left = load_tree_from_disk(file);
new_node->right = load_tree_from_disk(file);
return new_node;
}

static int load_avl_tree(struct lkdb *avl, const char *filename)

{
FILE *file = fopen(filename, "r");
if (!file)
return LKDB_FAILED_TO_OPEN_DB_FILE;
avl->root = load_tree_from_disk(file);
fclose(file);
return 0;
}

//
// Journalling
//

static int truncate_transaction_file(struct lkdb *avl)

{
FILE *file = fopen(avl->journalname, "wb");
if (!file)
return LKDB_FAILED_TO_OPEN_DB_FILE;
fclose(file);
return LKDB_SUCCESS;
}

static int add_transaction(struct lkdb *avl, uint8_t op, lkdb_key_t *key, lkdb_value_t *value)
{
FILE *file = fopen(avl->journalname, "ab");
if (!file)
return LKDB_FAILED_TO_OPEN_DB_FILE;
fwrite_uint8_t(op, file);
fwrite_uint32_t((uint32_t)strlen(key), file);
fwrite_str(key, file);
if (op == 43)
{
fwrite_uint32_t((uint32_t)strlen(value), file);
fwrite_str(value, file);
}
fclose(file);
return 0;
}

static int apply_all_transactions(struct lkdb *avl)

{
uint32_t l;
uint8_t *v, *key, *value;
FILE *file = fopen(avl->journalname, "r+b");
if (!file)
return LKDB_FAILED_TO_OPEN_DB_FILE;
uint8_t op;
while (1)
{
if (fread_uint8_t(&op, file) < 0)
{
fclose(file);
118 | P a g
e
 return LKDB_SUCCESS;
}
if (fread_uint32_t(&l, file) < 0)
{
fclose(file);
return LKDB_UNEXPECTED_EOF;
}
if (fread_str(&v, l, file) < 0)
{
fclose(file);
return LKDB_UNEXPECTED_EOF;
}
key = strdup(v);
free(v);
if (op == 43)
{
if (fread_uint32_t(&l, file) < 0)
{
fclose(file);
return LKDB_UNEXPECTED_EOF;
}
if (fread_str(&v, l, file) < 0)
{
fclose(file);
return LKDB_UNEXPECTED_EOF;
}
value = strdup(v);
free(v);
insert(key, value, &avl->root);
free(key);
free(value);
}
else
{
remove_(key, &avl->root);
free(key);
}
}
fclose(file);
return LKDB_SUCCESS;
}

//
// AVL tree internals
//

static inline int max(int a, int b) { return a > b ? a : b; }

static inline int min(int a, int b) { return a < b ? a : b; }
static inline void fix_diffs_right(int *ap, int *bp)
{
int a = *ap, b = *bp, k = (b > 0) * b;
*ap = k + (a - b) + 1;
*bp = max(b, k + a + 1) + 1;
}
static inline void fix_diffs_left(int *ap, int *bp)
{
int a = *ap, b = *bp, k = (b < 0) * b;
*ap = k + (a - b) - 1;
*bp = min(b, k + a - 1) - 1;
}

static inline void rotate_right(struct node **rp)

119 | P a g
e
{
struct node *a = *rp, *b = a->left;
a->left = b->right;
b->right = a;
fix_diffs_right(&a->diff, &b->diff);
*rp = b;
}

static inline void rotate_left(struct node **rp)

{
struct node *a = *rp, *b = a->right;
a->right = b->left;
b->left = a;
fix_diffs_left(&a->diff, &b->diff);
*rp = b;
}

static inline int balance(struct node **rp)

{
struct node *a = *rp;
if (a->diff == 2)
{
if (a->right->diff == -1)
rotate_right(&a->right);
rotate_left(rp);
return 1;
}
else if (a->diff == -2)
{
if (a->left->diff == 1)
rotate_left(&a->left);
rotate_right(rp);
return 1;
}
return 0;
}

static int insert_leaf(lkdb_key_t *key, lkdb_value_t *value, struct node **rp)

{
struct node *a = (*rp = malloc(sizeof *a));
if (a == NULL)
return LKDB_FAILED_TO_ALLOC_MEMORY;
a->left = a->right = NULL;
a->diff = 0;
a->key = strdup(key);
a->value = strdup(value);
return 1;
}

static int insert(lkdb_key_t *key, lkdb_value_t *value, struct node **rp)

{
struct node *a = *rp;
if (a == NULL)
return insert_leaf(key, value, rp);
if (strcmp(key, a->key) == 0)
{
free(a->value);
a->value = strdup(value);
return 0;
}
if (strcmp(key, a->key) > 0)
if (insert(key, value, &a->right) && (++a->diff) == 1)
120 | P a g
e
 return 1;
if (strcmp(key, a->key) < 0)
if (insert(key, value, &a->left) && (--a->diff) == -1)
return 1;
if (a->diff != 0)
balance(rp);
return 0;
}

static int unlink_left(struct node **rp, struct node **lp)

{
struct node *a = *rp;
if (a->left == NULL)
{
*rp = a->right;
*lp = a;
return 1;
}
if (unlink_left(&a->left, lp) && (++a->diff) == 0)
return 1;
if (a->diff != 0)
return balance(rp) && (*rp)->diff == 0;
return 0;
}

static int remove_root(struct node **rp)

{
int delta;
struct node *a = *rp, *b;
if (a->left == NULL || a->right == NULL)
{
*rp = a->right == NULL ? a->left : a->right;
free(a->key);
free(a->value);
free(a);
return 1;
}
delta = unlink_left(&a->right, rp);
b = *rp;
b->left = a->left;
b->right = a->right;
b->diff = a->diff;
free(a->key);
free(a->value);
free(a);
if (delta && (--b->diff) == 0)
return 1;
if (b->diff != 0)
return balance(rp) && (*rp)->diff == 0;
return 0;
}

static int remove_(lkdb_key_t *key, struct node **rp)

{
struct node *a = *rp;
if (a == NULL)
return 0;
if (strcmp(key, a->key) == 0)
return remove_root(rp);
if (strcmp(key, a->key) > 0)
if (remove_(key, &a->right) && (--a->diff) == 0)
return 1;
121 | P a g
e
 if (strcmp(key, a->key) < 0)
if (remove_(key, &a->left) && (++a->diff) == 0)
return 1;
if (a->diff != 0)
return balance(rp) && (*rp)->diff == 0;
return 0;
}

static void free_(struct node *a)

{
if (a == NULL)
return;
free_(a->left);
free_(a->right);
free(a);
}

static struct node *leaf_left(struct node *root)

{
if (root == NULL)
return NULL;
leaf_left(root->left);
return root;
}

static struct node *leaf_right(struct node *root)

{
if (root == NULL)
return NULL;
leaf_right(root->right);
return root;
}

static int valid(struct node *a)

{
int lh, rh, b;
if (a == NULL)
return 0;
lh = valid(a->left);
if (lh < 0)
return lh;
rh = valid(a->right);
if (rh < 0)
return rh;
b = rh - lh;
if (b != a->diff)
return LKDB_INTERNAL_BALANCE_ERR;
if (abs(b) > 1)
return LKDB_LOPSIDED_ERR;
return max(lh, rh) + 1;
}

static void inorder(struct node *root)

{
if (root == NULL)
return;
inorder(root->left);
if (root->key != NULL && root->value != NULL)
{
printf("%s: %s (%d)\n", root->key, root->value, root->diff);
}
inorder(root->right);
122 | P a g
e
}

static int inorder_count(struct node *root)

{
if (root == NULL)
return 0;
return inorder_count(root->left) + 1 + inorder_count(root->right);
}

//
// Public API
//

struct lkdb *bhai_ek_db_bnao(char *filename)

{
generate_CRC32_table();
struct lkdb *avl = malloc(sizeof *avl);
if (avl == NULL)
return NULL;
avl->root = NULL;
if (filename == NULL)
{
avl->dbname = NULL;
avl->journalname = NULL;
}
else
{
avl->dbname = strdup(filename);
avl->journalname = malloc(strlen(filename) + 5);
if (avl->journalname != NULL)
sprintf(avl->journalname, "%s%s", filename, ".jnl");
else
avl->journalname = NULL;
}
if (filename != NULL)
load_avl_tree(avl, filename);
apply_all_transactions(avl);
return avl;
}

void bhai_ye_db_delete_kr_do(struct lkdb *db)

{
free_(db->root);
if (db->dbname != NULL)
free(db->dbname);
if (db->journalname != NULL)
free(db->journalname);
free(db);
}

void bhai_ye_value_rakhna(struct lkdb *db, char *key, char *value)

{
if (db->journalname != NULL)
add_transaction(db, 43, key, value);
insert(key, value, &db->root);
}

void bhai_ye_value_delete_krna(struct lkdb *db, char *key)

{
if (db->journalname != NULL)
add_transaction(db, 45, key, NULL);
remove_(key, &db->root);
123 | P a g
e
}

struct lkdb_lookup_result *bhai_ye_value_dekhna(struct lkdb *db, char *key)

{
struct lkdb_lookup_result *r = NULL;
struct node *n = avl_search(key, db->root);
if (n == NULL)
return NULL;
r = malloc(sizeof *r);
if (r == NULL)
return NULL;
r->key = strdup(n->key);
r->value = strdup(n->value);
return r;
}

void bhai_ye_dekhna_aur_delete_krna(struct lkdb_lookup_result *r)

{
free(r->key);
free(r->value);
free(r);
}

int bhai_db_sahi_toh_hai_na(struct lkdb *db)

{
return valid(db->root);
}

void bhai_inorder_print_krna(struct lkdb *db)

{
printf("--\n");
if (db->root == NULL)
{
printf("Empty!\n");
return;
}
printf("Left:\n");
inorder(db->root->left);
printf("Root:\n");
if (db->root->key != NULL && db->root->value != NULL)
{
printf("%s: %s (%d)\n", db->root->key, db->root->value, db->root->diff);
}
printf("Right:\n");
inorder(db->root->right);
}

int bhai_iska_size_btana(struct lkdb *db)

{
if (db->root == NULL)
return 0;
return inorder_count(db->root);
}

static struct node *avl_search(lkdb_key_t *key, struct node *root)

{
if (root == NULL)
return NULL;
if (strcmp(root->key, key) == 0)
return root;
if (strcmp(key, root->key) > 0)
return avl_search(key, root->right);
124 | P a g
e
 else
return avl_search(key, root->left);
}

int cmp = strcmp(key, a->key);

if (cmp == 0)
{
free(a->value);
a->value = strdup(value);
return 0; // Updated existing key
}
else if (cmp < 0)
{
int inserted = insert(key, value, &a->left);
if (inserted > 0)
{
a->diff--;
if (a->diff == -2)
{
balance(rp);
return 0;
}
}
return inserted;
}
else
{
int inserted = insert(key, value, &a->right);
if (inserted > 0)
{
a->diff++;
if (a->diff == 2)
{
balance(rp);
return 0;
}
}
return inserted;
}
}

#ifndef LKDB_H
#define LKDB_H

#include <stdint.h>

#define LKDB_SUCCESS 0
#define LKDB_INTERNAL_BALANCE_ERR -1001
#define LKDB_LOPSIDED_ERR -1002
#define LKDB_DBNAME_IS_NULL -1003
#define LKDB_FAILED_TO_OPEN_DB_FILE -1004
#define LKDB_FAILED_TO_ALLOC_MEMORY -1005
#define LKDB_UNEXPECTED_EOF -1006

typedef uint8_t lkdb_key_t;

typedef uint8_t lkdb_value_t;

struct node
{
lkdb_key_t *key;
lkdb_value_t *value;
struct node *left;
125 | P a g
e
 struct node *right;
int diff; // Balance factor
};

struct lkdb
{
struct node *root;
uint8_t *dbname;
uint8_t *journalname;
// Add other members as needed
};

struct lkdb_lookup_result
{
lkdb_key_t *key;
lkdb_value_t *value;
};

struct lkdb *bhai_ek_db_bnao(char *filename);

void bhai_ye_db_delete_kr_do(struct lkdb *db);
void bhai_ye_value_rakhna(struct lkdb *db, char *key, char *value);
void bhai_ye_value_delete_krna(struct lkdb *db, char *key);
struct lkdb_lookup_result *bhai_ye_value_dekhna(struct lkdb *db, char *key);
void bhai_ye_dekhna_aur_delete_krna(struct lkdb_lookup_result *result);
int bhai_db_sahi_toh_hai_na(struct lkdb *db);
void bhai_inorder_print_krna(struct lkdb *db);
int bhai_db_save_kr_do(struct lkdb *db);
int bhai_iska_size_btana(struct lkdb *db);

#endif // LKDB_H

Testing

126 | P a g
e
Results:
Expected Results and Evaluation of the LKDB Project:
The successful completion of the Language-Friendly Key-Value Pair Database (LKDB) project
is anticipated to yield a functional and demonstrably language-agnostic key-value data store.
The primary outcome will be a core storage engine capable of reliably persisting and retrieving
key-value pairs. This engine will be evaluated based on its efficiency in basic CRUD operations
(create, read, update, delete), its ability to handle concurrent access without data corruption
(depending on the chosen concurrency control mechanism), and its overall stability.
Performance benchmarks, measuring read and write throughput, will be conducted to assess the
engine's efficiency, particularly when storing and retrieving data of varying sizes.
A crucial aspect of the project's success will be the development and functionality of the
language-specific client libraries. These libraries, implemented for target languages such as
Python, JavaScript, Java, and Go, are expected to provide a consistent and intuitive API for
interacting with the LKDB. The evaluation of these libraries will focus on their ease of use, the
transparency of the underlying serialization and deserialization processes, and their ability to
seamlessly integrate with the idiomatic programming styles of each language. Tests will verify
that data stored using one language's client can be accurately retrieved and interpreted by clients
in other supported languages, confirming the language interoperability objective.
The choice and implementation of the data serialization format will be a key determinant of the
project's success in achieving language neutrality. The results will demonstrate the effectiveness
of the chosen format (likely JSON initially) in representing common data types across different
languages without loss of information or requiring complex transformations. The project will
also explore the feasibility and benefits of alternative serialization formats like Protocol Buffers
for potential future enhancements in efficiency and schema evolution.
Furthermore, the project aims to provide comprehensive documentation, including API
references for each client library, architectural overviews, and usage examples. The quality and
clarity of this documentation will be a significant factor in evaluating the project's usability and
its potential for adoption by developers working in multi-language environments.
If a networked version of LKDB is implemented as a future enhancement, the results will
include an evaluation of its network performance, its ability to handle multiple concurrent client
connections from different languages, and the robustness of the defined communication
protocol. Security considerations, while potentially basic in the initial phase, will also be noted
for future development.
Ultimately, the success of the LKDB project will be measured by its ability to provide a simple,
efficient, and truly language-friendly solution for data storage and retrieval in polyglot
application development. Demonstrating seamless data exchange and ease of integration across
diverse programming languages will be the primary indicator of its value and the achievement
of its core objectives. The performance benchmarks, usability of the client libraries, and the
clarity of the documentation will further contribute to the overall evaluation of the project's
outcomes.

Discussion:
The Language-Friendly Key-Value Pair Database (LKDB) aims to simplify data sharing in
polyglot applications. By utilizing a universal data serialization format like JSON and providing
intuitive client libraries for languages like Python, JavaScript, Java, and Go, LKDB minimizes
language-specific data handling. This approach fosters developer productivity by enabling
seamless data exchange across different parts of a system, regardless of the underlying
227 | P a g
e
programming language. The project explores a lightweight and efficient key-value store
designed for language interoperability, offering a streamlined solution compared to adapting
traditional databases for diverse language environments. LKDB has the potential to
significantly ease development in multi-language architectures.

Conclusion:
The Language-Friendly Key-Value Pair Database (LKDB) project set out to address the
complexities of data management in modern, polyglot application environments. By prioritizing
language interoperability as a core design principle, LKDB offers a streamlined and efficient
solution for storing and retrieving data across a diverse range of programming languages. The
project's foundation lies in the adoption of a universally accessible data serialization format, such
as JSON, which enables seamless data exchange without the need for intricate language-specific
transformations. Furthermore, the development of intuitive client libraries tailored for popular
languages like Python, JavaScript, Java, and Go provides developers with familiar and easy-to-
use interfaces, abstracting away the underlying data handling and communication mechanisms.

The implementation of LKDB involved the creation of a core storage engine, capable of
performing fundamental CRUD operations. While initial implementations might leverage simple
file-based storage for portability, future iterations could integrate more robust embedded key-
value stores like RocksDB or LevelDB to enhance performance and scalability. The focus on a
straightforward key-value model inherently simplifies data interaction compared to the often
complex schema management and query languages associated with traditional relational or even
some NoSQL databases. This simplicity, coupled with the language-agnostic data format and
client libraries, significantly reduces the cognitive load and development time associated with
cross-language data sharing.

The expected results of the LKDB project demonstrate its potential to be a valuable tool in the
evolving landscape of software development. The ability to seamlessly store and retrieve data
across different language boundaries fosters greater flexibility in architectural design, allowing
development teams to leverage the strengths of various programming languages without the
burden of complex data integration challenges. The performance benchmarks conducted on the
core storage engine, along with the usability assessments of the client libraries, provide tangible
evidence of LKDB's efficiency and ease of adoption. The comprehensive documentation further
enhances its accessibility, making it easier for developers to understand and integrate LKDB into
their multi-language projects.

While the initial scope of LKDB may focus on basic key-value operations and a limited set of
data types, the architecture is designed to be extensible. Future enhancements could include
support for more complex data structures, advanced querying capabilities, and the development
of a networked server component to enable distributed deployments. The exploration of
alternative serialization formats like Protocol Buffers could further optimize performance and
facilitate schema evolution.

In conclusion, the Language-Friendly Key-Value Pair Database represents a significant step

towards simplifying data management in polyglot environments. By prioritizing language
interoperability at its core, LKDB offers a lightweight, efficient, and user-friendly solution that
empowers developers to build more flexible and integrated applications, ultimately contributing
to increased productivity and more seamless cross-language collaboration. The project's success
lies not only in its technical implementation but also in its ability to address a growing need in
the modern software development landscape.

228 | P a g
e