Uravu is the object relationship intelligence engine yet to be developed for Injee. If done right, it will be the stepping stone for GraphQL, ORM classes export in various languages, and will enable Database Script export which will properly include foreign keys.

Injee was created to increase front end developers productivity massively, and it should also decrease the load on back end developers in the times ahead. Till today human needed to model a Database for CRUD app, no matter even if you use advanced frameworks like Ruby on Rails, Django etc. This is waste of time. We believe that a REST request too server, in a span of time holds enough information to model a database in a automated way. This is what we would like to develop in the near or far future depending on this cosmos makes us tick.

When modelling relationships between tables, there can be many types of relationships, this is how injee will detect it.

has one

A record can be related to another record in a way that it has only one relation with record in another table, and not anymore. This is called has one relation.

There is a table named citizens, and a citizen can have only one passport, so in injee it will be modelled as shown:

{
  "citizens": [{
    "id": "e9b3cd95-861e-414e-9417-c6267b51c222",
    "name": "Aravindan"
  }]
}

{
  "passports": [{
    "id": "......",
    "citizen_id": "e9b3cd95-861e-414e-9417-c6267b51c222",
    "number": "12345678"
  }]
}

There is a table passports, and a passport has a column named citizen_id that points to a citizen. Injee will scan for columns that has _id at its end, in this case its citizen_id, it will check if there is a table named citizen or citizens, if yes it will check if there is a citizen with id e9b3cd95-861e-414e-9417-c6267b51c222, if yes, injee will relate to it.

has many

In the ata structures below user has many owned books, one can model it as shown, where there is a table called users, and a user can have many books

{
  "users": [{
    "id": "e9b3cd95-861e-414e-9417-c6267b51c222",
    "name": "Aravindan"
  }]
}

{
  "books": [
    {
      "id": "......",
      "user_id": "e9b3cd95-861e-414e-9417-c6267b51c222",
      "title": "The Lord of the Rings"
    },
    
    {
      "id": "......",
      "user_id": "e9b3cd95-861e-414e-9417-c6267b51c222",
      "title": "The Hobbit"
    }
  ]
}

If you look at both the book records shown above, you can see that the user_id points to the same user. Injee will be smart to realize that this is a has many relationship. That is users has many books.

belongs to

A citizen can have a passport as shown:

{
  "citizens": [{
    "id": "e9b3cd95-861e-414e-9417-c6267b51c222",
    "name": "Aravindan"
  }]
}

{
  "passports": [{
    "id": "......",
    "citizen_id": "e9b3cd95-861e-414e-9417-c6267b51c222",
    "number": "12345678"
  }]
}

This means a passport belongs to a citizen, Injee will be smart enough to identify it.

has and belongs to many (habtm)

A book can have many authors, and an author can have many books, this is called has and belongs to many relation. It can be represented as follows.,

{
  "authors": [{
    "id": "aravindan_id",
    "name": "Aravindan"
  },
  {
    "id": "karthikeyan_id",
    "name": "Karthikeyan"
  }]
}

{
  "books": [{
    "id": "clojure_id",
    "title": "Clojure",
  },
  {
    "id": "python_id",
    "title": "Python",
  }]
}

{
  "authors_books": [{
    "author_id": "aravindan_id",
    "book_id": "python_id"
  },
  {
    "author_id": "karthikeyan_id",
    "book_id": "clojure_id"
  },
  {
    "author_id": "karthikeyan_id",
    "book_id": "python_id"
  }]
}

Look at the table authors_books above, it contains author_id and book_id. Injee should be smart enough to identify this is habtm. But, how we create this authors_books from CRUD interface or something? Should we hit POST /authors_books endpoint with data? For now maybe yes. Or what if we have hit POST /authors and POST /books endpoints with filed named book_id[] and author_id[]? The latter seems more elegant right?

Automatic model detection

So how does Injee detect a table is related to another table? One hint is, if the key is say user_id or users_id, and if there is table named users then Injee will detect it. But what if there is table named users, and user owns books, and if the key in books is owned_by_id, still Injee should detect it. Welcome to the magic of UUID.

{
  "users": [{
    "id": "e9b3cd95-861e-414e-9417-c6267b51c222",
    "name": "Aravindan"
  }]
}

{
  "books": [
    {
      "id": "......",
      "owned_by_id": "e9b3cd95-861e-414e-9417-c6267b51c222",
      "title": "The Lord of the Rings"
    },
    
    {
      "id": "......",
      "owned_by_id": "e9b3cd95-861e-414e-9417-c6267b51c222",
      "title": "The Hobbit"
    }
  ]
}

In the case above, Injee will check if there is a table named owned_by or it will try to pluralize it and see if there is a table in that name. If not, its UUID value is used. This could be expensive, but we believe that computers should work for us and no the other way around.

Polymorphism

Say you have a table named details with the following data:

{
  "details": [{
    "id": "e9b3cd95-861e-414e-9417-c6267b51c222",
    "name": "Aravindan",
    "description": "My name is Aravindan",
    "belongs_to_id": "user_aravindan_uuid"
  },
  {
    "id": "e9b3cd95-861e-414e-9417-c6267b51c222",
    "name": "Data Scientists",
    "description": "A group for Data Scientists",
    "belongs_to_id": "group_data_scientists_uuid"
  }]
}

belongs_to_id in the first record points to a record in users table, and in the second record, points to a record in groups table. Injee should be smart enough to detect it, and deduce that this is a polymorphic relationship.

Advantages

The advantage is that, the front end dev gets seamless experience. One is able to hit some URLs, and when one requires DB scripts to create databases, or ORM’s that needs to be generated in Python, Ruby or what ever language, those get generated seamlessly along with relations and foreign keys. If we implement GraphQL support in Injee, this uravu project will come handy for us. This should look like magic if we do our work right

Disadvantages

The disadvantage we fear is performance, let’s say that one has a gigabyte of data in memory, and we want to process it, may be the uravu engine will take time to process, maybe it could crash your system due to limited memory. We just don’t know. But we will give it a shot. We firmly believe in future fast volatile and slow permanent storage will blend to form fast permanent storage, then the equation for Databases will change and size of data will not matter much, even if it’s a lot.