I'm writing a Project in Django where I've 5 kind of groups of Users:
Group1
Group2
...
Then I've a Model, Item which has many relation with users, the Item has one Owner (a User in Group1), a Customer (an User in Group2) and many RelatedUser (Users in Group3).
I'm wondering which is the correct way to write this relations. I'd love to write something like:
class Item(models.Model):
owner = models.ForeignKey(Owner)
customer = models.ForeignKey(Customer)
users = models.ManyToManyField(RelatedUser)
Having defined in some way Owner, Customer and RelatedUser classes.
I do not know how to achieve this. I do not want to use model inheritance, because I just want a table User. Even Managers does not seems to help me. Actually I'm using something like this:
try:
customer = models.ForeignKey(User,
related_name='cust',
limit_choices_to = {'groups__in': [Group.objects.get(name = 'customers')]})
except:
customer = models.ForeignKey(User,
related_name='cust')
Mostly because when starting form an empty database Group 'customers' does not exists and errors are raised.
Which is the right way to afford this?
Thanks in advance
You could define separate models for each user type - each with a ForiegnKey to User. The upside is simplicity, but the down side is that this approach adds multiple tables, and isn't particularly extensible if you need to add more groups later.
Another option is to define a Groups model, which stores the different types of groups available, and has a ManyToMany relationship to User (assuming one user can be in multiple groups).
You can get around the problem of no groups being defined when starting from a new database by creating a fixture for the Groups model . A fixture is a text file (default is JSON format) that defines a set of data that can be easily loaded into the DB, either automatically or manually. Fixtures can be easily created from existing data with the dumpdata management command.
If you wish a fixture to be loaded automatically (when you run syncdb), create a fixtures directory in your app, and name the fixture initial_data. You can also create other fixtures and load them with either the loaddata command, or in your tests by specifying a fixtures list for a particular TestCase
Related
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
Say I have a User model in django and I want to add some achievements to users. So I've created an Achieve model:
class Achive:
type = ....
value = ....
status = BooleanField(default=False)
I want all those achieves be a static set of models for every user (20 instances, for example) with ability to delete old and create new achieves. The problem is how to do it. Expected flow is:
1) user granted to use achievement system;
2) user got all those achieves (in admin panel shows like a table);
3) in admin panel per user I can change status of every achieve (affects only on edited user);
4) if new Achieve instance is created — add to all users who have achievements;
5) if existed Achieve instance has been deleted — remove from all users;
Solutions with I came up:
1) use Achieve model with jsonfield. store achieves in json like dictionary, use custom widget for admin panel to show checkboxes to change status). But where to store global set of achievements to create new/delete old ones? how to manage it?
2) use many to many field to Achieve and Achieve model without status. Why: if relation between User ← → Achieve exists, that means that user earn an achieve.
Both solutions I don't really like so hope for your advice.
P.S. sqlite is used as db and not allowed to use another (like mongo, etc.)
Thanks in advance!
What you want is a ManyToMany relationship between Achieve and User, but with the ability to store extra data on the relationship (the status for example).
With a normal ManyToManyField on a Model, Django actually creates an intermediate model to store the relationships in the database. By adding a through argument to your ManyToManyField, you can specify the intermediate model used for the relationship and store extra data with the relationship, as documented here:
class Goal(models.Model):
type = ...
value = ...
achievers = models.ManyToManyField(to=User, through='Achievement', related_name='goals')
class Achievement(models.Model):
status = models.BooleanField()
date_reached = models.DateField(null=True)
goal = models.ForeignKey(to=Goal, on_delete=models.CASCADE)
achiever = models.ForeignKey(to=User, on_delete=models.CASCADE)
then you can create and query the relationships like this, assuming you have a user and a goal:
achievement = Achievement.objects.create(status=True, date_reached=date(2018, 10, 12), achiever=user, goal=goal)
user.goals.filter(achievement__status=True) # gives the achieved goals of a user
goal.achievers.filter(achievement__status=True) # gives the users that achieved a goal
I have designed my models such way that all the models will have one to one relation on auth_user table which is User. For your quick reference I am pasting the Picture below
Now I want to select all the data related to username which are in tables BasicDetails, Department and Project. The below query is not fetching the results.
User.objects.select_related().get(username='user1')
Can someone help me on this?
-Vikram
You should use prefetch_related for efficiency, since your relation is reverse (you want to access the other records from User and not the other way around):
u = User.objects.prefetch_related('project_set', 'department_set', 'basicdetails_set').get(username='user1')
This will not generate a single query, but Django will use caching techniques to effectively produce less possible db overhead. If I recall correctly it will produce 4 queries (a single join in 4 tables might be slower anyway, depending on number of records, indexes etc). The benefit is that on subsequent requests no queres will be generated. For example to get a user's projects:
u.project_set.all() #hits the db
u.project_set.all() #cached version, no db hit
For more info see here https://docs.djangoproject.com/en/dev/topics/db/queries/#one-to-one-relationships.
EDIT: what is project_set?
If your Project model is defined like this
class Project(models.Model):
...
user = models.ForeignKey(User)
then you can do Project.objects.get(pk=1).user to access the user associated to a project instance, but how would you do the opposite (get all projects of a certain user)? Django will automatically include a '_set' property to the other model for convenience. Therefore we can get the projects of a certain user like this:
u = User.objects.get(pk=1)
user_objects = u.project_set.all()
However if you want to explicitly set a name for this reverse relation, django allows you define the ForeignKey with a related_name keyword argument like this:
class Project(models.Model):
...
user = models.ForeignKey(User, related_name='projects')
Now instead of .project_set you could use .projects to access a user's projects:
u = User.objects.get(pk=1)
user_objects = u.projects.all()
I have a django based web shop that has been evolving over the past year. Currently there's about 8 country specific shops running through the same code base, plus an API, and there's soon to be a B2B website, and a few more countries to add to the list.
Variations are needed in model structure, particularly around fields in address models, the account model, and so on.
To make matters a bit more complicated, the site is running multidb with each shop instance in a separate db. So I have a situation where I might have a base ABC model, e.g:
class Address(models.Model):
class Meta:
abstract=True
class Address_UK(Address):
class Meta:
db_table="shop_address"
class Address_IT(Address):
class Meta:
db_table="shop_address"
[etc]
Then code throughout the app to select the the correct model, e.g.
if countrysettings.country == "UK":
address = Address_UK()
elif countrysettings.country == "IT":
address = Address_IT()
The countrysettings.country is actually a separate settings class which subclasses threading.local and the country code, which also corresponds with a key in settings.DATABASES, is configured by a geolocation middleware handler. So the correct database is selected, and the model specific variations are reflected in each country database.
But there are problems to this approach:
It completely breaks syncdb and is no good for south, unless I hack ./manage.py so I can pass in the country db, instead of requiring the middleware to set it.
It seems messy. So much if countrysettings.country == "xx": code lying about, and so many sub classed models.
So I was thinking of using django-eav instead, but I foresee problems in the admin, and in particular field ordering. I know that django-eav will build a modelform for the admin that includes the eav fields, but I'd ideally want these to be displayed or hidden relevant to the country.
Also I've considered having a none abstract base class, e.g. Address, and then creating country specific variations where needed (e.g Model Table Inheritance). But then I foresee the base models getting overloaded with one2one fields to each model variant. But it would solve issues with the admin.
Another option might be to have an extra data field, and to serialise additional fields into json or csv or something and store them in this field.
I can think about a few others way to attack your problem. I believe option 1 or option 2 are the best, but one might choose option 3.
Option 1: One code base, One db, One django instance, Sites framwork: If you do not actually need a distinct db for each store, create all tables and/or all possible fields, and smartly use the sites framework for condour fields fields and models. For example: keep for each address a address_type field etc and use different fields (and tables) on the same db for each site. This makes your code more complicated but simplifies your IT a lot. Use this if the code changes between sites is very minimal. (btw - The json serialization is a good option for address).
Option2: One code base, Many DBs, Many django instances: Set many sites with the same code base but carefully use conditional settings and dynamic features of python to generate different models per site. Each site will have it's own settings-uk.py, settings-us.py etc., and will have it's own db and own models using dynamic models. For example:
from django.conf import settings
# ...
class Address(models.Model):
name = models.CharField(max_length=100)
if settings.country == "US":
state = models.CharField(max_length=2)
else:
country = models.CharField(max_length=100)
Other possible tricks for this method: Enable/disable apps via the settings; Crafting custom pythonpaths for appsin the wsgi script/manage.py script; use if settings.country=='us': import uk_x as x else: import us_x as x . See also: http://code.flickr.com/blog/2009/12/02/flipping-out/
Option3: Parallel code branches, Many DBs, Many django instances: Use git to keep a few branches of your code and rebase them with each other. Requires much more IT effort. If you are planning to have many db and many server, (and many developers?) anyway, you might find this useful.
Another options: One DB, many django instances custom settings.py per instance without sites framework.
Actually EAV can solve your issue. You can in fact use EAV to show fields that a specific to the country attribute of the current object.
Here is an example
class Country(models.Model):
name = models.CharField(_("country"), max_length=50
class Address(eav.models.BaseEntity):
country = models.ForeignKey(Country, related_name="country_attrs")
# EAV specific staff
#classmethod
def get_schemata_for_model(self):
# When creating object, country field is still not set
# So we do not return any country-specific attributes
return AddressEAVSchema.objects.filter(pk=-1).all()
def get_schemata_for_instance(self, qs):
# For specific instance, return only country-specific attributes if any
try:
return AdressEAVSchema.objects.filter(country=self.country).all()
except:
return qs
# Attributes now can be marked as belonging to specific country
class AdressEAVSchema(eav.models.BaseSchema)
country = models.ForeignKey(Country, related_name="country_attrs")
# Rest of the standard EAV stuff
class AdressEAVChoice(eav.models.BaseChoice):
schema = models.ForeignKey(AdressEAVSchema, related_name='choices')
class AddressEAVAttribute(eav.models.BaseAttribute):
schema = models.ForeignKey(AdressEAVSchema, related_name='attrs')
choice = models.ForeignKey(AdressEAVChoice, blank=True, null=True)
Here how to use it:
When you create Address attributes you now have also to specify which country they belong to.
Now, when you create new Address object itself (say in admin), save, and then go back editing it you see additional country-specific attributes that match objects country.
Hope this helps.
So I've got a UserProfile in Django that has certain fields that are required by the entire project - birthday, residence, etc. - and it also contains a lot of information that doesn't actually have any importance as far as logic goes - hometown, about me, etc. I'm trying to make my project a bit more flexible and applicable to more situations than my own, and I'd like to make it so that administrators of a project instance can add any fields they like to a UserProfile without having to directly modify the model. That is, I'd like an administrator of a new instance to be able to create new attributes of a user on the fly based on their specific needs. Due to the nature of the ORM, is this possible?
Well a simple solution is to create a new model called UserAttribute that has a key and a value, and link it to the UserProfile. Then you can use it as an inline in the django-admin. This would allow you to add as many new attributes to a UserProfile as you like, all through the admin:
models.py
class UserAttribute(models.Model):
key = models.CharField(max_length=100, help_text="i.e. Age, Name etc")
value = models.TextField(max_length=1000)
profile = models.ForeignKey(UserProfile)
admin.py
class UserAttributeInline(admin.StackedInline):
model = UserAttribute
class UserProfile(admin.ModelAdmin):
inlines = [UserAttibuteInline,]
This would allow an administrator to add a long list of attributes. The limitations are that you cant's do any validation on the input(outside of making sure that it's valid text), you are also limited to attributes that can be described in plain english (i.e. you won't be able to perform much login on them) and you won't really be able to compare attributes between UserProfiles (without a lot of Database hits anyway)
You can store additional data in serialized state. This can save you some DB hits and simplify your database structure a bit. May be the best option if you plan to use the data just for display purposes.
Example implementation (not tested)::
import yaml
from django.db import models
class UserProfile(models.Model):
user = models.OneToOneField('auth.User', related_name='profile')
_additional_info = models.TextField(default="", blank=True)
#property
def additional_info(self):
return yaml.load(self._additional_info)
#additional_info.setter
def additional_info(self, user_info_dict):
self._additional_info = yaml.dump(user_info_dict)
When you assign to profile.additional_info, say, a dictionary, it gets serialized and stored in _additional_info instead (don't forget to save the instance later). And then, when you access additional_info, you get that python dictionary.
I guess, you can also write a custom field to deal with this.
UPDATE (based on your comment):
So it appears that the actual problem here is how to automatically create and validate forms for user profiles. (It remains regardless on whether you go with serialized options or complex data structure.)
And since you can create dynamic forms without much trouble[1], then the main question is how to validate them.
Thinking about it... Administrator will have to specify validators (or field type) for each custom field anyway, right? So you'll need some kind of a configuration option—say,
CUSTOM_PROFILE_FIELDS = (
{
'name': 'user_ip',
'validators': ['django.core.validators.validate_ipv4_address'],
},
)
And then, when you're initializing the form, you define fields with their validators according to this setting.
[1] See also this post by Jacob Kaplan-Moss on dynamic form generation. It doesn't deal with validation, though.