Database Schema (Model)

Relevant source files

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

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

The core of the LostData application is the management of "Model" data. This is primarily handled through a Node.js backend using Express and Mongoose, which connects to a MongoDB database. The central data structure is the Model schema, defining the attributes and information stored for each model profile. The database connection is configured to use either a MongoDB URI from environment variables or a local default.

A parallel, standalone Python script also exists, which manages similar data in a local models.json file, suggesting an alternative or perhaps initial version of the data management system. The primary, active system for the web application, however, is the Node.js/MongoDB stack.

Sources: APP/models/model.model.js, server.js:23, APP/config/db.config.js:2, model_database.py

Node.js (Mongoose) Implementation

The main application uses Mongoose to define and interact with the Model schema in a MongoDB database. The setup is modular, with separate files for database configuration, schema definition, and model initialization.

Sources: APP/models/index.js, APP/models/model.model.js

Schema Definition

The Model schema is defined in APP/models/model.model.js. It includes fields for personal details, professional information, pricing, and content guidelines. It also features an automated history tracking mechanism.

// APP/models/model.model.js:2-15
module.exports = mongoose => {
  var schema = mongoose.Schema(
    {
      id: { type: String, required: true, unique: true },
      name: { type: String, required: true },
      age: { type: Number },
      location: { type: String },
      profile: { type: String, required: true },
      pricing: { type: String, required: true },
      dosAndDonts: { type: String, required: true },
      extraTabs: { type: Array, default: [] },
      history: { type: Array, default: [] }
    },
    { timestamps: true }
  );

Sources: APP/models/model.model.js:2-15

The following diagram illustrates the Model entity and its attributes as defined in the Mongoose schema.

Schema Fields

Field	Type	Constraints/Defaults	Description
id	String	required: true, unique: true	A unique string identifier for the model (e.g., roxie_sinner_001).
name	String	required: true	The model's name.
age	Number	-	The model's age.
location	String	-	The model's location.
profile	String	required: true	A detailed profile description.
pricing	String	required: true	Pricing information for services.
dosAndDonts	String	required: true	A list of allowed and disallowed activities.
extraTabs	Array	default: []	An array for additional information tabs.
history	Array	default: []	An array that logs changes to the document.
timestamps	Object	true	Automatically adds createdAt and updatedAt fields.

Sources: APP/models/model.model.js:4-14, seed.js:5-7

Middleware for History Tracking

The schema includes a pre('save') middleware hook. This function automatically pushes a new entry into the history array whenever an existing document is modified. The history entry includes a timestamp, the action ('update'), and a list of the modified fields.

// APP/models/model.model.js:17-25
  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:17-25

Database Connection and Initialization

The application's entry point, server.js, establishes the connection to MongoDB. The connection string is sourced from APP/config/db.config.js, which prioritizes an environment variable MONGODB_URI over a default local instance. The APP/models/index.js file centralizes the Mongoose setup, exporting a db object containing the Mongoose instance and the compiled Model.

Python Implementation (model_database.py)

A standalone Python script, model_database.py, provides a command-line interface to manage model data stored in a models.json file. This appears to be a separate utility and does not interact with the Node.js application or MongoDB.

Sources: model_database.py

ModelDatabase Class

The script defines a ModelDatabase class to handle all data operations. It can load, save, add, remove, and view models. The data is stored in memory as a dictionary and persisted to models.json.

The following diagram shows the structure of the ModelDatabase class.

Data Structure

The Python script uses a nested dictionary structure to store model data, with the model's name as the top-level key. This differs slightly from the Mongoose schema, notably by separating dos and donts into distinct list properties.

{
    "ROXIE SINNER": {
        "pricing": "...",
        "dos": ["Fully Nude: TRUE", "..."],
        "donts": ["Femdom Videos: FALSE", "..."],
        "profile": "..."
    }
}

Sources: model_database.py:25-31, 88-202

Data Seeding and Interaction

Database Seeding

The seed.js script is used to populate the MongoDB database with initial data. It connects to the database, defines an array of model objects (modelsData), and uses the Mongoose insertMany function to perform a bulk insertion. This is a one-off script to ensure the database is not empty on a fresh setup.

API Endpoints

The server.js file defines a RESTful API for CRUD operations on the Model collection. These endpoints are used by the frontend to fetch, display, create, update, and delete model data. Admin-only endpoints for data import/export are also provided.

Method	Endpoint	Protection	Description
GET	/api/models	Public	Fetches all models, sorted by name.
GET	/api/models/:id	Public	Fetches a single model by its _id.
POST	/api/models	Admin	Creates a new model.
PUT	/api/models/:id	Admin	Updates an existing model by its _id.
DELETE	/api/models/:id	Admin	Deletes a model by its _id.
GET	/api/export/json	Admin	Exports all models as a JSON file.
GET	/api/export/csv	Admin	Exports all models as a CSV file.
POST	/api/import/csv	Admin	Imports models from an uploaded CSV file.

Sources: server.js:46-140, public/index.html:80-155

The sequence diagram below shows the flow for a client fetching the list of all models.

Summary

The LostData project's data persistence is centered around the Model entity, which is robustly defined using a Mongoose schema for the primary web application. This schema includes detailed fields, timestamps, and an automated history-tracking mechanism. The application exposes this data via a REST API with role-based access controls. A separate Python script offers a CLI-based alternative for managing similar data in a JSON file, but the Node.js/MongoDB implementation is the core of the live system.

Sources: APP/models/model.model.js, server.js, model_database.py