I'm working on a project that is scheduled to be deployed in phases. In each of those phases, a specific table will progressively receive additional fields. As I already know which fields will be added in the future, I could added those just now and let them be empty for now until the next phases are reached, but I was wondering a different strategy. I was thinking in implement the first phase's table and in the subsequent phases create new table in which each of its fields are OneToOne related to the first table.
I'm doing this right? Sounds like a good strategy?
ps.: I'm not a native English speaker. I apologize for any mistake. :)
You might want to look at Django South. It can help migrate schemas. So if you want to add fields to existing tables, South will help you.
There's plenty of documentation at their website, and also from other sources.
Related
I am working on a database intensive project where there are lots of schemas and tables/views etc that are created in these schemas.
My question is around the best practice or recommended practice on to what schema should all the DBT deployed models should belong to?
One option is to have them belong to different schemas based on its definition.
Other option is to have them all belong to same schema that is separate from the other schemas already existing in the database, so we can lookup using the particular schema name.
You're asking a great question! Albiet, one without one right answer.
From the dbt docs's Using Aliases page:
The names of schemas and tables are effectively the "user interface" of your data warehouse. Well-named schemas and tables can help provide clarity and direction for consumers of this data. In combination with custom schemas, model aliasing is a powerful mechanism for designing your warehouse.
Perhaps the answer is:
Do what you think is best for your users. You are making a library. what's the easiest way for folks to find what they are looking for?
I'm struggling at building a website with Django. On that website, I want to have a lot of information about TV shows. I want my user to be able to insert and modify information. The information needs to be moderated, a change should not be published before being accepted by a moderator.
I came across django-moderation as a solution to that aspect.
My user will log into another instance of django-admin, with different user rights.
I'm adding django-guardian to deal with per-object permissions.
I'm lost a bit lost now. I think I'll find how to interface all those things, and it will work in a few weeks after reading all the docs, making all the mistakes, etc...
I am wondering thou if the architecture makes sense, if are software components I am missing out on.
Thank you for your consideration.
edit : BTW, working with django 1.7 on python 3.4
django-moderation looks interesting, I haven't used it. There's not a lot of activity in the project, but it's active. I think it will suit the use-case you have in mind. I considered django-guardian recently for a project and rejected it in favour of extending tastypie's authorizations. I think my use case was a bit different, I needed to maintain constraints on foreign key relationships that were hard to express with django-guardian. If you only intend to allow or reject read/write permissions and don't need to validate anything beyond rudimentary data points, it will do a good job (in that case, use Django's model validators).
In general: Django has a wide assortment of easily included apps. in general: if you can solve it with pip install, do so.
I have to create a django project which has two dictinct parts. The producer provides some UI to the user and eventually writes to some models. The consumer uses this data and does some processing and shows some pretty graphs etc.
Technically, these are completely isolated apps used by completely distinct user set. I would love to make them separate django projects altogether but unfortunately they share the db structure. The database is effectively a pipe that connects the two.
How should I structure the project? From what I read, I should ideally have isolated models per app. Unfortunately that is not possible.
Any recommendations?
If you define a "app" and use it inside of your "Django Project" I assume you use INSTALLED_APP's in settings.py to make it known within your environment.
If you look it from this point - its the same as if you use "django-social-auth" in two different projects/services and you share the same DB. I can't judge if its common or uncommon to use the same DB, its a design decision you have to make and you need to be happy with.
If you just like to have users and webusers seperated in your admin, please have a look at
separating-staff-and-user-accounts
I have a weird legacy database use-case: I have multiple databases, with (1) exactly the same schema, but (2) very different datasets. Databases, entire databases, with this schema, are being added to the total dataset every week.
Is there a way to (1) introspect the server to find out what databases are available, and if so, is there a way to (2) route to the correct database by URL, rather than by the current per-model solution (since my models don't change, only the associated underlying tables)?
Can this introspection be made dynamic, so every time someone hits the home page I can show them the list of available databases?
A generic solution is preferable, of course, but a MySQL-only solution is currently acceptable.
(The use case in the European Molecular Biology Lab's genome library, which is published every few months as a suite of MySQL database dumps, one database per species, with a core schema of about twenty tables which map nicely to six or so apps. The schema is stable and hasn't changed in years.)
Yes, you are able to run any raw SQL, and show databases is not exception. But it will be hard to change list of available databases and to switch between them. I'm afraid this will require modification or monkey patching of django's internals.
Update: Wait! I've looked into the code behind the django.db.connections and found that if you just extend settings.DATABASES in runtime, then you'll be able to use SomeModel.objects.using('some-new-database').all() in the code. Have not tested, but belive this should work!
I'm working on a subset of my projects functionality, and I'm trying to focus on breaking my project into focused apps (as opposed to one monolithic app that does it all). After some googling, I want to keep each app tight and focused. However, I'm not exactly sure of the best way to divide up my code.
The overall functionality has three basic components:
Employees and their associated information.
Certificates/employee training and certificate information. Basically different types of training employees can receive and associated information.
Employee certifications (this links certificates to employees).
I have three main models: Employee, Certificate and Certification (which shares a relationship with both Employees and Certificates).
I could throw all three into a single app, as all three objectives are somewhat related, or, I could divide up the work. In the latter, two of the three are easy: employees and certificates can both exist without the other and have their own app, but certificates I'm not so sure about.
I could:
Bundle certifications in the employee or certificate app
Give certifications their own app
What say you? Does this scenario warrant more than one app? And if so, how should the three functionality requirements be divided up to keep each one tight and focused?
I would keep them all in a single app. It's too simple of an app (personally) for me to break it up. I would take advantage of django.contrib.auth.models.Users and build off of that in a structure which looks like this.
To take advantage of the users structure you need to extend the User model. Stackoverflow answers here and official documentation here.
HTH
I would advice to keep them in a single app : so all your models go into a single models.py,
and rather have multiple views.py (say for every functional unit).
This way, you can manage your models easily and also hit the right views file as required.
Keeping in multiple apps in this case would be an overkill, as there is no clear demarcation between the functionalities.