<commit_before>#encoding: utf-8

from django.db import models

#Haitham:   (how models works? will the following model be defined in 1 database?)
#Haitham:   (what does foreign key means?)
#Haitham:   how the different model interact?
#Haitham:   can we change the models (add/remove fields) in the future?
#Haitham:   how to store user comments EFFICIENTLY? do we have to deal with it now?
#Haitham:   how the data is stored? by a stand alone data base for each layer (can layer be added dynamically by admins)?
#           or by a generic field in the data database (can we define a generic field)?
#           i guess that a stand alone data base for each layer is better
#   where the physical data base will be created?
#   what is the optimal char fields length

class UserBasic(models.Model):<commit_msg>answering haitham questions<commit_after>#encoding: utf-8

from django.db import models

#Haitham:   (how models works? will the following model be defined in 1 database?)
#daonb: all models are deifned in one database - as define in the project's settings.py
#Haitham:   (what does foreign key means?)
#daonb: a one-to-many relationship, helping you connect two models using a 
#       direct, non-exclusive link from one models to another. 
#       please use the related_name of attributed of ForeignKey field to 
#       better name the reverse relationship.
#Haitham:   how the different model interact?
#daonb: using ForeignKeys and ManyToMany relatinshps for start
#Haitham:   can we change the models (add/remove fields) in the future?
#daonb: it's tricky, but the south app helps
#Haitham:   how to store user comments EFFICIENTLY? do we have to deal with it now?
#daonb: no. "We should forget about small efficiencies, say about 97% of the time: 
#       premature optimization is the root of all evil" <NAME>
#Haitham:   how the data is stored? by a stand alone data base for each layer (can layer be added dynamically by admins)?
#           or by a generic field in the data database (can we define a generic field)?
#           i guess that a stand alone data base for each layer is better
#daonb: not necessarly. we should keep the number of the 'moving parts' to a minimum and
#       sql databases are fully capble of handling all our layers in one database
#   where the physical data base will be created?
#   daonb: in the database defined in the project's settings.py
#   what is the optimal char fields length
#   daonb: use TextField and don't worry about running out of chars

class UserBasic(models.Model):
{'fraction_non_alphanumeric': 0.05704169944925256, 'fraction_numerical': 0.0023603461841070024, 'mean_word_length': 3.7532710280373833, 'pattern_counts': {'":': 0, '<': 4, '<?xml version=': 0, '>': 4, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5720377', 'n_tokens_mistral': 709, 'n_tokens_neox': 693, 'n_words': 385}