Context:
I'm playing around with setting up a DRF project using the postgresql sample database located here: Postresql Sample DB
Problem:
The sample database is already set up with intermediate tables film_category and film_actor. When using manage.py to inspectdb it generates these intermediate tables explicitly (FilmCategory and FilmActor) and they serve no purpose in the code as they only contain the ids for the two related fields. If I were to create them using the Django ORM I could just declare:
class Film(models.Model):
...
actors = models.ManyToManyField(Actor, related_name='films')
Django creates these tables "behind the curtain" so they take up no space in my code. I attempted to just set up a ManyToManyField like so:
actors = models.ManyToManyField(Actor, db_table='film_actor', related_name='films')
categories = models.ManyToManyField(Category, db_table='film_category', related_name='films')
When attempting to migrate, however, this fails giving me the following error:
psycopg2.errors.DuplicateTable: relation "film_actor" already exists
I don't think I want to create this ManyToManyField without explicitly telling it which db_table to use because I believe that would generate an entirely new intermediate table and I lose access to all the data already stored in those intermediate tables in the original sample database.
I was able to get it to work without errors and the expected operations function normally by doing:
actors = models.ManyToManyField(Actor, through='FilmActor', related_name='films')
But now I have an explicitly defined FilmActor and FilmCategory model sitting in my models.py that I cannot remove without causing errors:
class FilmActor(models.Model):
actor = models.ForeignKey(Actor, models.CASCADE)
film = models.ForeignKey(Film, models.CASCADE)
last_update = models.DateTimeField()
class FilmCategory(models.Model):
film = models.ForeignKey(Film, models.CASCADE)
category = models.ForeignKey(Category, models.CASCADE)
last_update = models.DateTimeField()
Has any dealt with explicitly defined intermediate tables generated from an existing DB with inspectdb? Is there a way to get rid of those models that were generated while still allowing the normal ManyToMany operations? Technically what I want to do is working, I just feel like having those two intermediate tables explicitly declared as models in my code when they have no additional data (other than "last_update") feels icky.
I have two Django projects that communicate with each other. The first one contains model A and B that has a ForeignKey to A. The first project sends and receives serialized B objects from the second project. I want the second project to contain just B, but it needs the value of that ForeignKey. These models are defined as follows:
class A(models.Model):
...
class B(models.Model):
fk = models.ForeignKey(to='A', on_delete=models.PROTECT)
...
The problem is that ForeignKey to A in model B requires model A to be defined in the second project. Its objects also have to exist so that the database is consistent and there are no problems, e.g., in the admin panel.
In the end, I'd like to treat the fk field as a full-fledged ForeignKey in the first project and as some kind of read-only generic identifier in the second one. Specifically, I need to retain the functionality of querying both ways in the first project, e.g., fk__some_a_field and b_set. I would like to have the same code base for the model in both projects to ensure databases in the two projects stay synchronized. How can I achieve this in a clean way?
EDIT:
I was also considering fk = CustomField(...) which would be more or less defined as
if IS_FIRST_PROJECT:
CustomField = ForeignKey
else:
CustomField = IntegerField
but the issue is that I'd need a clean way to select the type of integer field that exactly matches the default foreign key. Also, I am not sure if such a solution could bring unexpected problems.
Specifically, I need to retain the functionality of querying both ways in the first project, e.g., fk__some_a_field and b_set.
If you want to use django orm, you would have to recreate your A model from project 1 in project 2. But as model A is managed by the project 1, consider adding next lines to your model in project 2:
class A(models.Model):
...
class Meta:
managed = False
db_table = 'your database table name where A model is stored'
managed=False would tell django to ignore migrations for it, and django won't be allowed to change that model's database table.
The other solution if you don't want to duplicate models from project 1 to project 2, is to not use django orm. And write sql queries by yourself. But as you mentioned you don't want to do this
P.S if you don't know how to see name of database table for model A, you can output it like this: a_model_instance._meta.db_table, or look it in some tools like pgadming if you are using postgres
To create a generic versioning for my models I have created a model Version:
class Version(models.Model):
version_number = models.IntegerField()
...
and an abstract models VersionedModel
class VersionedModel(models.Model):
...
versions = models.ManyToManyField(Version, related_name="%(app_label)s_%(class)s")
class Meta:
abstract = True
everything works but I would like to have the database check that each version is assigned to one and only one object.
What I can think of is to modify the field versions and use through to create and intermediate table where I could then use a unique index on version_id, but I am just back to the initial problem of creating a ForeingKey field to an abstract model.
I don't like using GenericForeignKey as they create all sort of headaches when working with graphene. I wondered if there is a way to model this in a different way, or to use some constraint I am not aware of, so that the database can provide completeness and uniqueness on its own.
I'm django learner and i have problem with django relationship concept.
I have written two models that have relations with single source model (UserProfile).but one of them does not work properly.The Message class work fine with it's two fields (sender,receiver),but the other class(Class) lead to
programing error:relation "CEA_class" already exists
where CEA is my app name.I really prefer to have two different field for the class and don't join them as single field.What I'm suppose to do with it?
class Message ---->that work fine
class Message(models.Model):
sender = models.ForeignKey(UserProfile,blank=False,related_name="sender")
receiver = models.ForeignKey(UserProfile,blank=False,related_name="receiver")
content = models.CharField(max_length=200)
priority = models.BigIntegerField(choices=PRIORITY_LIST,default=1)
class Class ---->that lead to error
class Class(models.Model):
subject = models.CharField(max_length=20)
time = models.CharField(max_length=20)
day = models.CharField(max_length=20)
location = models.CharField(max_length=20)
students = models.ManyToManyField(UserProfile,blank=True,related_name="students")
master = models.ForeignKey(UserProfile,blank=True,related_name="master")
Here is my whole UserProfile class
class UserProfile(models.Model):
user=models.OneToOneField(User,
related_name='UserProfile',on_delete=models.CASCADE)
field=models.CharField(max_length=20,default="ce")
userPhoto=models.ImageField(upload_to='documents/',blank=True)
Type=models.BigIntegerField(choices=USER_TYPE,default=2)
gender=models.BigIntegerField(choices=GENDER_TYPE,default=1)
def __str__(self):
return self.user.username
#The decorator can also takes extra arguments which are passed onto the
signal
#receiver(post_save,sender=User)
def create_or_update_UserProfile(sender, instance, created, **kwargs):
if created:
UserProfile.objects.create(user=instance)
instance.UserProfile.save()
I have an error in my admin page as below:
.
ProgrammingError at /admin/CEA/class/
column CEA_class.master_id does not exist LINE 1: ...time",
"CEA_class"."day", "CEA_class"."location", "CEA_class...
I solved this a while ago and found some references including in the Django doc, but I'm actually still not quite sure why this is needed as the underlying SQL structure doesn't (as far as I can tell in looking at my own database) show the variance in related_name - it appears to be an internal Django issue rather than an actual SQL issue. In any case, when you have more than one field related to the same other model within a table then all except one have to have something referencing the class in order to get Django to keep things straight. It is often cleanest to add class to ALL the related_names within a model that has the problem for consistency, though I have checked my own code and sometimes I do that, sometimes I don't:
students = models.ManyToManyField(UserProfile,blank=True,related_name="%(class)s_students")
master = models.ForeignKey(UserProfile,blank=True,related_name="%(class)s_master")
After all i came to this conclusion that the best way for deleting the Annoying irrelevant data that cause the problems is to temporary rename the model and migrate and then rename it to it's first name.By this way django itself take care of deleting relations and every data in database that causes your problem.
With all these interpretations,all of the suggested answers was helpful but i think the simple is better,why not. :))
This is a problem concerning django.
I have a model say "Automobiles". This will have some basic fields like "Color","Vehicle Owner Name", "Vehicle Cost".
I want to provide a form where the user can add extra fields depending on the automobile that he is adding. For example, if the user is adding a "Car", he will extra fields in the form, dynamically at run time, like "Car Milage", "Cal Manufacturer".
Suppose if the user wants to add a "Truck", he will add "Load that can be carried", "Permit" etc.
How do I achieve this in django?
There are two questions here:
How to provide a form where the user can add new fields at run time?
How to add the fields to the database so that it can be retrieved/queried later?
There are a few approaches:
key/value model (easy, well supported)
JSON data in a TextField (easy, flexible, can't search/index easily)
Dynamic model definition (not so easy, many hidden problems)
It sounds like you want the last one, but I'm not sure it's the best for you. Django is very easy to change/update, if system admins want extra fields, just add them for them and use south to migrate. I don't like generic key/value database schemas, the whole point of a powerful framework like Django is that you can easily write and rewrite custom schemas without resorting to generic approaches.
If you must allow site users/administrators to directly define their data, I'm sure others will show you how to do the first two approaches above. The third approach is what you were asking for, and a bit more crazy, I'll show you how to do. I don't recommend using it in almost all cases, but sometimes it's appropriate.
Dynamic models
Once you know what to do, this is relatively straightforward. You'll need:
1 or 2 models to store the names and types of the fields
(optional) An abstract model to define common functionality for your (subclassed) dynamic models
A function to build (or rebuild) the dynamic model when needed
Code to build or update the database tables when fields are added/removed/renamed
1. Storing the model definition
This is up to you. I imagine you'll have a model CustomCarModel and CustomField to let the user/admin define and store the names and types of the fields you want. You don't have to mirror Django fields directly, you can make your own types that the user may understand better.
Use a forms.ModelForm with inline formsets to let the user build their custom class.
2. Abstract model
Again, this is straightforward, just create a base model with the common fields/methods for all your dynamic models. Make this model abstract.
3. Build a dynamic model
Define a function that takes the required information (maybe an instance of your class from #1) and produces a model class. This is a basic example:
from django.db.models.loading import cache
from django.db import models
def get_custom_car_model(car_model_definition):
""" Create a custom (dynamic) model class based on the given definition.
"""
# What's the name of your app?
_app_label = 'myapp'
# you need to come up with a unique table name
_db_table = 'dynamic_car_%d' % car_model_definition.pk
# you need to come up with a unique model name (used in model caching)
_model_name = "DynamicCar%d" % car_model_definition.pk
# Remove any exist model definition from Django's cache
try:
del cache.app_models[_app_label][_model_name.lower()]
except KeyError:
pass
# We'll build the class attributes here
attrs = {}
# Store a link to the definition for convenience
attrs['car_model_definition'] = car_model_definition
# Create the relevant meta information
class Meta:
app_label = _app_label
db_table = _db_table
managed = False
verbose_name = 'Dynamic Car %s' % car_model_definition
verbose_name_plural = 'Dynamic Cars for %s' % car_model_definition
ordering = ('my_field',)
attrs['__module__'] = 'path.to.your.apps.module'
attrs['Meta'] = Meta
# All of that was just getting the class ready, here is the magic
# Build your model by adding django database Field subclasses to the attrs dict
# What this looks like depends on how you store the users's definitions
# For now, I'll just make them all CharFields
for field in car_model_definition.fields.all():
attrs[field.name] = models.CharField(max_length=50, db_index=True)
# Create the new model class
model_class = type(_model_name, (CustomCarModelBase,), attrs)
return model_class
4. Code to update the database tables
The code above will generate a dynamic model for you, but won't create the database tables. I recommend using South for table manipulation. Here are a couple of functions, which you can connect to pre/post-save signals:
import logging
from south.db import db
from django.db import connection
def create_db_table(model_class):
""" Takes a Django model class and create a database table, if necessary.
"""
table_name = model_class._meta.db_table
if (connection.introspection.table_name_converter(table_name)
not in connection.introspection.table_names()):
fields = [(f.name, f) for f in model_class._meta.fields]
db.create_table(table_name, fields)
logging.debug("Creating table '%s'" % table_name)
def add_necessary_db_columns(model_class):
""" Creates new table or relevant columns as necessary based on the model_class.
No columns or data are renamed or removed.
XXX: May need tweaking if db_column != field.name
"""
# Create table if missing
create_db_table(model_class)
# Add field columns if missing
table_name = model_class._meta.db_table
fields = [(f.column, f) for f in model_class._meta.fields]
db_column_names = [row[0] for row in connection.introspection.get_table_description(connection.cursor(), table_name)]
for column_name, field in fields:
if column_name not in db_column_names:
logging.debug("Adding field '%s' to table '%s'" % (column_name, table_name))
db.add_column(table_name, column_name, field)
And there you have it! You can call get_custom_car_model() to deliver a django model, which you can use to do normal django queries:
CarModel = get_custom_car_model(my_definition)
CarModel.objects.all()
Problems
Your models are hidden from Django until the code creating them is run. You can however run get_custom_car_model for every instance of your definitions in the class_prepared signal for your definition model.
ForeignKeys/ManyToManyFields may not work (I haven't tried)
You will want to use Django's model cache so you don't have to run queries and create the model every time you want to use this. I've left this out above for simplicity
You can get your dynamic models into the admin, but you'll need to dynamically create the admin class as well, and register/reregister/unregister appropriately using signals.
Overview
If you're fine with the added complication and problems, enjoy! One it's running, it works exactly as expected thanks to Django and Python's flexibility. You can feed your model into Django's ModelForm to let the user edit their instances, and perform queries using the database's fields directly. If there is anything you don't understand in the above, you're probably best off not taking this approach (I've intentionally not explained what some of the concepts are for beginners). Keep it Simple!
I really don't think many people need this, but I have used it myself, where we had lots of data in the tables and really, really needed to let the users customise the columns, which changed rarely.
Database
Consider your database design once more.
You should think in terms of how those objects that you want to represent relate to each other in the real world and then try to generalize those relations as much as you can, (so instead of saying each truck has a permit, you say each vehicle has an attribute which can be either a permit, load amount or whatever).
So lets try it:
If you say you have a vehicle and each vehicle can have many user specified attributes consider the following models:
class Attribute(models.Model):
type = models.CharField()
value = models.CharField()
class Vehicle(models.Model):
attribute = models.ManyToMany(Attribute)
As noted before, this is a general idea which enables you to add as much attributes to each vehicle as you want.
If you want specific set of attributes to be available to the user you can use choices in the Attribute.type field.
ATTRIBUTE_CHOICES = (
(1, 'Permit'),
(2, 'Manufacturer'),
)
class Attribute(models.Model):
type = models.CharField(max_length=1, choices=ATTRIBUTE_CHOICES)
value = models.CharField()
Now, perhaps you would want each vehicle sort to have it's own set of available attributes. This can be done by adding yet another model and set foreign key relations from both Vehicle and Attribute models to it.
class VehicleType(models.Model):
name = models.CharField()
class Attribute(models.Model):
vehicle_type = models.ForeigngKey(VehicleType)
type = models.CharField()
value = models.CharField()
class Vehicle(models.Model):
vehicle_type = models.ForeigngKey(VehicleType)
attribute = models.ManyToMany(Attribute)
This way you have a clear picture of how each attribute relates to some vehicle.
Forms
Basically, with this database design, you would require two forms for adding objects into the database. Specifically a model form for a vehicle and a model formset for attributes. You could use jQuery to dynamically add more items on the Attribute formset.
Note
You could also separate Attribute class to AttributeType and AttributeValue so you don't have redundant attribute types stored in your database or if you want to limit the attribute choices for the user but keep the ability to add more types with Django admin site.
To be totally cool, you could use autocomplete on your form to suggest existing attribute types to the user.
Hint: learn more about database normalization.
Other solutions
As suggested in the previous answer by Stuart Marsh
On the other hand you could hard code your models for each vehicle type so that each vehicle type is represented by the subclass of the base vehicle and each subclass can have its own specific attributes but that solutions is not very flexible (if you require flexibility).
You could also keep JSON representation of additional object attributes in one database field but I am not sure this would be helpfull when querying attributes.
Here is my simple test in django shell- I just typed in and it seems work fine-
In [25]: attributes = {
"__module__": "lekhoni.models",
"name": models.CharField(max_length=100),
"address": models.CharField(max_length=100),
}
In [26]: Person = type('Person', (models.Model,), attributes)
In [27]: Person
Out[27]: class 'lekhoni.models.Person'
In [28]: p1= Person()
In [29]: p1.name= 'manir'
In [30]: p1.save()
In [31]: Person.objects.a
Person.objects.aggregate Person.objects.all Person.objects.annotate
In [32]: Person.objects.all()
Out[33]: [Person: Person object]
It seems very simple- not sure why it should not be a considered an option- Reflection is very common is other languages like C# or Java- Anyway I am very new to django things-
Are you talking about in a front end interface, or in the Django admin?
You can't create real fields on the fly like that without a lot of work under the hood. Each model and field in Django has an associated table and column in the database. To add new fields usually requires either raw sql, or migrations using South.
From a front end interface, you could create pseudo fields, and store them in a json format in a single model field.
For example, create an other_data text field in the model. Then allow users to create fields, and store them like {'userfield':'userdata','mileage':54}
But I think if you're using a finite class like vehicles, you would create a base model with the basic vehicle characteristics, and then create models that inherits from the base model for each of the vehicle types.
class base_vehicle(models.Model):
color = models.CharField()
owner_name = models.CharField()
cost = models.DecimalField()
class car(base_vehicle):
mileage = models.IntegerField(default=0)
etc