Database Configuration

Relevant source files

The following files were used as context for generating this wiki page:

• APP/config/db.config.js
• server.js
• APP/models/index.js
• APP/models/model.model.js
• seed.js
• package.json
• model_database.py

The LostData project utilizes a MongoDB database for its primary data persistence, managed through a Node.js backend. The interaction with the database is facilitated by the Mongoose Object Data Modeling (ODM) library. Configuration is handled via a dedicated file, which allows for flexibility between development and production environments using environment variables.

In addition to the primary MongoDB setup, a secondary, self-contained Python script provides an alternative data management system using a local JSON file. This suggests two parallel methods for data handling within the project's ecosystem. This document outlines the architecture, configuration, and data models for both systems.

Node.js & MongoDB Implementation

The core of the application relies on a Node.js server connecting to a MongoDB instance. This setup is responsible for handling all API requests for creating, reading, updating, and deleting model data.

Sources: server.js, APP/config/db.config.js, APP/models/index.js, APP/models/model.model.js, package.json

Configuration

Database connection details are centralized in APP/config/db.config.js. The configuration provides the MongoDB connection URI. It prioritizes an environment variable MONGODB_URI for production or containerized setups and falls back to a local MongoDB instance if the variable is not set.

// APP/config/db.config.js
module.exports = {
  url: process.env.MONGODB_URI || "mongodb://127.0.0.1:27017/model_db"
};

Sources: APP/config/db.config.js:1-3

Connection and Initialization

The main server file, server.js, initiates the database connection on startup. It imports the consolidated database object from APP/models/index.js, which has already configured Mongoose and loaded the data models.

The connection flow is as follows:

1. server.js requires APP/models.
2. APP/models/index.js requires APP/config/db.config.js to get the connection URL.
3. APP/models/index.js initializes a db object containing the Mongoose instance, the URL, and the compiled Model schema from model.model.js.
4. server.js calls db.mongoose.connect() using the URL from the db object.

This diagram illustrates the database initialization process when the server starts.

Data Schema: Model

The application uses a single primary schema for "Models," defined in APP/models/model.model.js. This schema dictates the structure of documents stored in the models collection in MongoDB.

The following diagram shows the structure of the Model entity.

Schema Fields

Field	Type	Constraints/Defaults	Description
id	String	required, unique	A unique identifier for the model.
name	String	required	The name of the model.
age	Number	-	The age of the model.
location	String	-	The location of the model.
profile	String	required	A detailed profile description.
pricing	String	required	Pricing information.
dosAndDonts	String	required	A list of "do's and don'ts".
extraTabs	Array	default: []	An array for additional information tabs.
history	Array	default: []	An audit log of changes made to the document. Automatically populated.

Sources: APP/models/model.model.js:4-12

Automatic History Tracking

The schema includes a pre('save') middleware hook. This function automatically adds an entry to the history array whenever an existing document is modified, tracking the timestamp, action type (update), and which fields were changed.

// APP/models/model.model.js
schema.pre('save', function(next) {
  if (this.isModified() && !this.isNew) {
    this.history.push({
      timestamp: new Date(),
      action: 'update',
      changes: this.modifiedPaths()
    });
  }
  next();
});

Sources: APP/models/model.model.js:18-27

Seeding the Database

The seed.js script provides a way to populate the database with initial data. It connects to the MongoDB instance using the same configuration and uses Model.insertMany() to bulk-insert an array of model objects. This is useful for setting up a development environment or for initial data deployment.

Sources: seed.js:1-125

Python & JSON Implementation

A separate Python script, model_database.py, offers a file-based alternative for managing model data. It uses a models.json file as its data store and provides a command-line interface (CLI) for interaction. This system is independent of the Node.js/MongoDB stack.

Sources: model_database.py

Architecture

The ModelDatabase class encapsulates all file I/O and data manipulation logic.

This diagram shows the flow of the Python script's interactive mode.

Class Methods

The ModelDatabase class provides the following methods for data management:

Method	Description
__init__(data_file)	Constructor, loads data from the specified JSON file.
load_data()	Loads model data from the JSON file into memory.
save_data()	Writes the current model data from memory to the JSON file.
add_model(...)	Adds or updates a model in the database.
remove_model(name)	Deletes a model by its name.
view_model(name)	Prints the full details of a specific model.
list_models()	Lists the names of all models currently in the database.
interactive_mode()	Starts a simple command-line interface for the user.

Sources: model_database.py:5-102

Summary

The project employs a dual-strategy for data persistence. The primary, production-ready system is a robust Node.js server connected to a MongoDB database, defined by a Mongoose schema with features like automatic history tracking. This is complemented by a standalone Python script that uses a simple JSON file for data storage, likely intended for local testing, data bootstrapping, or as an alternative management tool. Both systems revolve around a similar "Model" data structure but are implemented with different technologies and are not directly connected.