-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Store Datatypes in database #80
Conversation
|
||
def create_datatype(name): | ||
def create_datatype(datatype_object): | ||
name = datatype_object.name | ||
return { | ||
'id': '_'.join(name.split()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can follow up with a PR to start using actual IDs here; there's some JS that will need to be updated too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍🏼
@@ -88,3 +88,7 @@ class QueryLog(BaseModel): | |||
datatype = models.CharField(max_length=30) | |||
source = models.TextField(max_length=100) | |||
destination = models.TextField(max_length=100) | |||
|
|||
class DataType(BaseModel): | |||
name = models.CharField(max_length=30) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems fine for the moment for the articles table NOT to have a foreign key to this one. WE can always change that in a migration later if we want the tables to link to each other and ensure integrity of the data type names. So I agree with this approach at least util we find need to enforce the dependency or follow the foreignkey relationship.
2474b13
to
bfd44e7
Compare
Closes #77.
Follow-up steps (future PRs):