Provides a library for rapidly prototyping with a data model with related objects that span 'types' or tables.

I wanted a super lightweight way to quickly up a data model from a JSON source, and one that I could easily implement across languages/platforms.

This is a simple library that provides a context for performing some simple ORM style behaviors for data with little to no up front configuration.

on simple conventions of the shape of data, while also allowing for inline configuration to handle more complex data and convention overrides. This is intended to be used for quick prototyping, and is meant to be eventually by a more robust ORM or data modeling library once the requirements are better understood.

• linking - it will link objects together based on conventions in the data e.g. _k field indicates a key. _{name} indicates a one-to-one reference to another table. _{name}_s indicates a one-to-many reference to another table.

• field transformations - it can perform transformations of the values of fields, such as a date string into a date object. This is configured with simple inline declarations.

• access - provides a simple way to access the data in the model, and to perform simple queries on the data

• Convention over Configuration - It will do the right thing with no configuration, but can be configured inline to handle more complex data or to override conventions.

Take in list or hierarchical data and perform a 'best effort' to create a linked data model from it based on conventions in the shape of the data or via additional metadata that is not necessary but supplemental. Can be mixed in as a

To put it another way it allows very quick modeling with data that is effectively schema mixed with data.

It can extend JSON data and link the data together via some field conventions.

It creates 'tables' to sort data on determined 'types' and 'keys' in the data.

There are two primary types expected - a container and an item.

In the simplest behavior if you give it an object it will determine if it is a container or an item.

if it is an item it will be inserted into the correct Table. If type is undetermined it will be added to the 'unknown' table (or throw an error in strict mode).

If it is a container it will create a table if one doesn't already exist based on the container name and definition and then add the items to the table.

Data Node: A data node that will be brought into the model

Data Node Type: The type of the data node.

Node Type Object Container: A data node that can contain other potential data nodes

Data Type: The type of the data within the model

graph TD
  DB(DB)
   
  %% Strict|Loose Test
  subgraph strictLooseTest
    ModeTest[Mode Test] --> PerformTest{Mode}
    PerformTest -->|Strict| StrictMode[Strict Mode]
    PerformTest --> |Loose| LooseMode[Loose Mode] --> ReturnFlow[ReturnFlow]   
    StrictMode --> ThrowError[Throw Error]
  end

   subgraph determineType 
     Type{Type?} 
     Type --> |Undetermined| UndeterminedType[Undetermined Type]
     Type --> |Determined| ReturnType[Return Type]
   end 
        UndeterminedType --> strictLooseTest
      
  %% Data Ingres
  subgraph Simple Data Ingres
    DataIngres[Ingres Data Node] --> DataType{Data Type?}
    DataType --> |Item| ItemType[DataInstance Type] --> InsertIntoDB[Insert Into DB]
    DataType --> |List| TypeContainer[DataType Container] --> GetTypeDescriptor[Get Type Descriptor] --> IterateOverData[Iterate Over Data] --> InsertIntoDB
    DataType --> |Container| ObjectContainer[Object Container]
          
          
    ObjectContainer --> IterateOverFields[Iterate Over Fields]
    IterateOverFields --> |Get Field Value| DataType
          
    InsertIntoDB -.-> PerformTransformations[Perform Field Transforms] -.-> PerformLinking[Link Data]      
  end 
          
          
  %% Error States
  style ThrowError fill:#f9c2c2,stroke:#f9c2c2,stroke-width:4px
  style ReturnFlow fill:#c2f9c2,stroke:#c2f9c2,stroke-width:4px
  style ReturnType fill:#c2f9c2,stroke:#c2f9c2,stroke-width:4px
    

{
  "unitedStates": {
    "data": [
      {
        "_k": "US_AL",
        "name": "Alabama"
      },
      {
        "_k": "US_AK",
        "name": "Alaska"
      },
      {
          "_k": "US_AZ",
          "name": "Arizona"
      }
    ]
  }
}

System Conventions

• _k field indicates a key
• _{name} indicates a one-to-one reference to another table
• _{name}_s indicates a one-to-many reference to another table
• a 'data' field indicates the object is a container, and data contains items

• Default to using _id as key field instead of _k just bc it is more common
• Nested 'Tables'
• Allow multiple calls of loadData
• Mutation/Addition
• Asynchronous

• Currently, it processes each object de novo, without awareness of expected shape. Probably want this in most cases. Can add with metadata, or version expectation and warnings when it's not doing this.

• ESLint
• Add pre-commit hooks
  • Prettier
  • ESLint
  • Tests

Table - defines a peer list of the same 'type' of data. Has a name