I have two different Django projects that are meant to run in parallel and do pretty different things.
However they need to share a common database table, the Client table..
Both projects contains multiple apps that needs to contain foreign keys mapped to that Client model..
I'm not sure what would be the best approach..
Assuming both projects are working on the same db, just import the model you want to reference to.
from first_project.some_app.models import Client, OtherSharedModel
class SomeModelInSecondProject(models.Model):
client = models.ForeignKey(Client)
Unfortunately, Django's support for multiple databases does not support cross-database relations. You could fake this on one of the systems (ie. have the table referenced, but handle the key refs yourself), but you would need to be very careful to document what you are doing to make sure you maintain referential integrity in the app that is 'faking' it.
I haven't tested it but another alternative, if you're sharing the same db and having both projects in the same server, is to just merge them into one project, organize their apps in different directories and if you must you can use two different setting files. Please see this question related to that: How to keep all my django applications in specific folder. It's just a different approach that doesn't require you to reference a different project (I'm not sure how recommendable that is).
Related
I have a Django application that does quite expensive computation and then populates a database. I would like to serve the results using the Django Rest Framework. I would like to keep the application and the API on separate server instances so that I can ensure that the outgoing API is never deprived of resources. This means that both projects will be using the same tables in a shared database. Is there a way to achieve this without at least one of the projects having to perform raw SQL queries? I.e. Can I share both the database and the models (with querysets etc) between two projects on separate servers? Or is that not possible?
Note: I've looked at a lot of similar questions but the answers were not useful.
Thanks!
We've lots of intranet projects written in Django. As projects grows auth is always painful and duplicated.
E.g. user needs to login to three internal systems:
http://192.168.x.x/proj1/
http://192.168.x.x/proj2/
http://192.168.x.x/proj3/
Basically he has to create three accounts on three systems. So I figured if the MySQL table auth_user and django_session could be shared (using MySQL federated table engine) across three django projects, login session and info could be shared. So create account once and login one and use all three systems.
Is it safe? Anyone done similar in practice?
Sharing auth and session tables is quite an acceptable solution as long as maintainers of each project are aware of this architecture.
Some issues to be aware of:
Each project needs to be aware of the data stored in session by the other projects in order not to overwrite it inadvertently. This is not an issue if you only use the session for authentication.
The messages framework will not work as expected. Again, this might not be an issue in your projects.
It's probably a good idea to use the same Django version across all projects. For example, Django 1.6 changed the way it stores sessions by default. The User model might also change between versions.
If you want to use a Custom User Model, you need to use the same model on all projects. This might be a good option if you need to share extra profile data across projects though.
Since all three projects will have access to the DB, you'd better consider those as a single project/entity from a security point of view. Some data may leak from one project to the other through the session and be exposed where it shouldn't.
Also, some security issues may arise: if for example two projects use inadvertently the same variable name to store conflicting data, considered safe by one project but unsafe by another, a user could inject malicious data which will be considered safe.
But these things could happen if you have a single project maintained by multiple programmers too. So, as long as you make sure these are not issues for your projects you should be fine.
I have a database in sqlite and I want to use Django to present it and make queries on it.
I know how to create a new database by creating new classes in models.py, but what is the best way to use Django to access an existing database?
This seems to be a question in two parts: firstly, how can one write django model classes to represent an existing database, and secondly how that interacts with syncdb.
The answer to the first of these is that django models are not expressive enough to describe every possible SQL database schema, and instead use a subset that works well with the ORM's usage pattern. Tnerefore you may need to accept some adjustments to your schema in order to describe it with django models. In particular:
Django does not support composite primary keys. That is, you can't have a primary key that spans multiple columns.
Django expects tables to be named appname_modelname, because this convention allows the tables from many apps to easily co-exist in the same database.
If your schema happens to match the subset that django models support or you are willing to make changes to adapt it to be so then your task is simply to write models that match with the schema. The inspectdb tool may provide a useful starting point.
You can test if you've been successful in describing your database by temporarily reconfiguring your project to use a different empty database and running manage.py syncdb, and then comparing the schema that Django created with the schema that already existed. If they are the same (or at least close enough) then you got it right.
If your existing database is not a good match for Django ORM's assumptions then a more flexible alternative is SQLAlchemy. It doesn't natively integrate into django's application system but it does provide a more complete database interface that can work with almost any database; some databases will be easy to map, and some others will require some more manual mapping work, but almost all cases should be possible with some creativity.
As for the interaction with syncdb: the default behavior for this command is to skip over any models that already seem to have tables in the database. Therefore if you've defined models that do indeed match with your existing database tables it should leave them alone. It will, however, create the additional tables required for other apps in your project, including Django's own tables.
Modern Django has support for multiple databases, which could provide you with a further approach: configure your existing database as a second database source in your project and use a database router to ensure that the appropriate models are loaded from that second database, and further to ensure that django won't attempt to run syncdb on this database. This provides true separation at the expense of some additional complexity, but it still requires that your schema be compatible with the ORM's assumptions. It also has some limitations, largely pertaining to relationships between objects that are persisted in different databases.
If you'd like to be able to make versioned changes to the database Django uses, starting with the schema you've inherited from the existing database, then South provides a more flexible and more complete alternative to the builtin syncdb mechanism that supports running arbitrary SQL data definition language statements to make changes to your database schema.
It sounds like you need something like South which will allow you to version and and revert changes to your models.
You just need ./manage.py inspectdb.
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'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.