Design Database

[adwait-thattey]

Issue to track progress of the database design

[adwait-thattey]

The way I plan the models right now is :

User
- All fields of django default User. Extend from AbstractUser

API
API is like a main method or command in tensorflow. (In git analogy an API could be git commit)

- name : VARCHAR
- usage : VARCHAR
- description : VARCHAR
- link to documentation : VARCHAR (URLField)

API Variant
API Variant is a variant of an API . (in git analogy, API VARIANT could be git commit --amend)
- api : FK to APIList
- usage : VARCHAR
- description : VARCHAR

SearchOption
These are searchable options for the user
- title : VARCHAR
- is_base : Bool
- children : ManyToManyField to self
- solutions : ManyToManyField to API
- solution_filter = ManyTomanyField to APIVariants

APISearchLog
- ContentType limited to API and APIVarient
- count

This should be good enough to get us started. We will add more as we increase the features.

Feel free to suggest any changes/ improvements

[masterashu]

what does parents mean in Options?

[adwait-thattey]

@masterashu Options are designed to be self linking. So, if you see gitexplorer there are multiple levels of search. So each search option will have parents. When we present user options for the next search, we present all its children as options. The base-level option will have no parent.

BTW I am still debating if having children instead of parents in the model makes more sense. Any thoughts?

[masterashu]

I think children would be better.

We could instead use Query and subquery, I believe that would make more sense.

[adwait-thattey]

I think SubQuery will be more expensive than having a join table in the db beforehand. I will look into it.

[masterashu]

I think SubQuery will be more expensive than having a join table in the db beforehand. I will look into it.

I actually meant the name of models, We could use Query instead of Option.

[adwait-thattey]

Lol. What was I thinking 😆
I would not prefer to use model names similar to built-in functions. Also, subquery will not be good because every option is not necessarily a subquery. Some option might be a base but also be a child of some other option. We need to be flexible regarding that.

[masterashu]

Okay, I understand.