I am new to Django and am working through some models on a project right now.
Is there a decent way to set the following up?
Using a model that ties to the auth_user model (UserAccount), I prompt users to select the type of account they have (Ex: Vendor or Buyer).
This part works fine... but I want to build the site experience based off of their account type. How would I create VendorProfile or BuyerProfile models (with differing data) based upon that option?
I might be over analyzing this, but basically I do not want any profiles to be linked to both types of data. Is that something I should just control with views, or is there a good way to lock my models and prevent duplicate information? Let me know if you think this is too broad, but I'm still on the conceptual level.
So:
auth_user model
UserAccount model:
user: one to one (User)
account_type: 'V' or 'B'
VendorProfile(?)
user: one to one (UserAccount where type='v')?
company name:
vendor code:
BuyerProfile(?)
user: one to one (UserAccount where type='b')?
favorite color:
pet's name:
yes you can do that. for that you need to change a small thing in the auth table of django and that is you need to add a column account_type where the V or B will be stored. Hope you can find it how to do it.
next is create 2 models for vendor and buyer. make a onetoonefield with the user table for storing the id of the user, in this models keep the extra information of the vendor or buyer you want to store.
hope it helps
Related
I am having trouble trying to decide what kind of relationship I should use for my application.
I want to have a database that shows something like...
A Movie table with fields title, year, language, description, duration and so on.
A User table with fields username, email
(I am new to django and am not worrying about authentications or passwords or any of that for now)
I want a user to be able to favorite a movie so I am trying to wrap my head around how it would actually work, for instance, would it be a user can favorite many movies and a movie can be favorited by many users (this makes sense to me) or is it a user can favorite many movies and a movie is favorited by a user.
so If I pick the second option I guess it would be a one-to-many rather than the first option which is a many-to-many relationship. However, I am not sure which one is actually correct.
After looking at the docs in django for many-to-one I see that a foreign key should be given to the Movie that references a user from User but they use an option that has on_delete=models.CASCADE and to my understanding it seems like the movie will be deleted if i were to delete the user which of course I don't want.
I was hoping for a detailed explanation as to which relationship it oughta be and if it is a many-to-one relationship then what kind of option should i use for instance the on_delete=models.CASCADE is probably not what I should use to my understanding
A given user can be in zero or more of the following categories:
floor staff
managers
owners
If the user is floor staff they require extra attributes (e.g. seniority and staffType).
My initial attempt looked something like this:
Create a Group for each category (this seems to make sense since each type of user should have different permissions within the site)
Create a FloorStaff model with the required extra attributes and a 1-to-1 relationship with User
Handle User creation and FloorStaff creation separately (i.e. using separate forms, accessed separately). The form to create FloorStaff adds the User to the floor staff group automatically.
While this works, it is not the most intuitive way to add a new floor staff employee to the site. From a manager's perspective, filling out 2 forms to add one employee makes little sense. That is, if I hire someone new, I should be able to fill out a "new employee" form that includes adding said employee to the correct categor(y/ies) at the same time as adding their basic info, and, if that employee is to be floor staff then the extra attributes should be added as well.
I've been toying with creating a custom user model that includes the extra attributes, but this feels wrong given that not all Users are FloorStaff.
At this point all I can think to do is to build a custom view and HTML form, but that too seems to go against the Django way of thinking.
What is the most "Djangoific" way to do this?
I would recommend making seniority and staffType as optional fields, and then create a custom model admin that enforces providing those fields when floor staff is true
I am writing a trip planner, and I have users. For the purposes of this question, lets assume my models are as simple as having a "Trip" model and having a "UserProfile" model.
There is a functionality of the site that allows to search for routes (via external APIs), and then dynamically assembles those into "trips", which we then display. A new search deletes all the old "trips" and figures out new ones.
My problem is this: I want to save some of these trips to the user profile. If the user selects a trip, I want it to be permanently associated with that profile. Currently I have a ManyToMany field for Trips in my UserProfile, but when the trips are "cleaned/flushed", all trips are deleted, and that association is useless. I need a user to be able to go back a month later and see that trip.
I'm looking for an easy way to duplicate that trip data, or make it static once I add it to a profile . .. I don't quite know where to start. Currently, the way it is configured is there is a trips_profile datatable that has a foreign key to the "trips" table . . . which would be fine if we weren't deleting/flushing the trips table all the time.
Help appreciated.
It's hard to say exactly without your models, but given the following layout:
class UserProfile(models.Model):
trips = models.ManyToManyField(Trip)
You can clear out useless Trips by doing:
Trip.objects.filter(userprofile__isnull=True).delete()
Which will only delete Trips not assigned to a UserProfile.
However, given the following layout:
class Trip(models.Model):
users = models.ManyToManyField(User)
You could kill the useless trips with:
Trip.objects.filter(users__isnull=True).delete()
The second method has the side benefit of not requiring any changes to UserProfile or even a UserProfile at all, since you can then just get a Users trips with:
some_user.trip_set.all()
I'm currently implementing a solution using django admin, it allows users to define in the db a product, and then custom attributes and details, more details may be aggregated by a common attribute, this allows me to query with ajax a custom view that returns some JSON data to build automagically the form fields that I need directly in the same formset view (manipulating the DOM).
The current DB design follows this schema:
Catalog(name, description, photo)
Product(rel_catalog, name, base_price, photo, manufacturer_email)
ProductDetail(rel_product, rel_attribute, percentage_price, fixed_price)
ProductAttribute(rel_product, name, description)
As you may see I have a catalog, where there can be more products, a lot of details per product, aggregated by attributes. Then I simple show by default the Catalog, then the select with all available products for that catalog, then, choosing the right Product, I obtain the complete form (each row has a label with ProductAttribute.name and a select with related ProductDetail).
All works pretty dam good, but I also need to store this references in the DB when someone completes the form (making an order with choosen products). This forms are displayed as StackedInline (the ModelAdmin is for the Order).
I don't know how many options there may be per product so I was thinking to use this design to track orders:
Order(customer, status, notes, tot_price, inserted_by)
OrderItem(rel_order, catalog, product, unit_price)
But I don't know how to store the dynamic added inputs...
I was thiking to implement OrderItemProperty(rel_orderitem, rel_productdetail, rel_productattribute) to store each single input... but how do I loop over this unknown fields?
Maybe do you suggest a better design?
If you need more code just ask for it and I'll reply with a pastebin link.
Thankyou.
Finally I got a working solution,
I've created a custom view, overriding the default "add/" view, this way I can customize whatever I want to and I can read the POST data handling each validation, putting then the data in the right model.
I have the following task.
Having three models Project, User and PurchaseOrder. I want to be able to create a membership for a User in a Project. A User can be a member in arbitrary Projects. This can be solved with a
ManyToManyField.
Additionally a membership should reference to a PurchaseOrder, since I want to assign the working hours to specific PurchaseOrders.
I think this could be solved by using a through-table for the ManyToManyField, and defining a ForeignKey to the PurchaseOrder model. Thus I would have for each membership a reference to a PurchaseOrder.
In reality a membership for a project will stay active, whereas after the money is spend for a PurchaseOrder, a new PurchaseOrder has to be assigned to the membership. This would also be easy by just updating the ForeignKey to a new PurchaseOrder.
But now my question:
I want to keep the old Project-membership-PurchaseOrder-Relation (data row in the membership table, for history tracking), set it to disabled and add a new Project-membership-PurchaseOrder-Relation, which would have the same ForeignKey to User and Project, but a different to the PurchaseOrder, and a flag set to enabled.
Is this a valid approach, will this work, will it be possible to circumvent uniqueness (or is there no uniqueness for the ManyToManyField by definition), or do you have a better idea how to do this?
When I read through this I can't figure out why even bother with the Many-to-Many relation for the Member > PurchaseOrder.
I would make it a One-to-Many relation for Member > PurchaseOrder and a Many-to-Many relation Member > Project, as the Membership appears to be the primarykey for it all.
In that way, you don't have to update any keys. Then I would create a fourth Model, having a Many-to-Many relation keeping track of the purchases. Adding the Membership prim. key and the PurchaseOrder prim.key.