Re: join on plain integerfield
Try Django Relativity: https://pypi.org/project/django-relativity/ -- Clive On 21 Nov 2022, at 10:11, Marek Rouchal wrote: Any suggestion how I can model such an integerfield, so that I can do joins on it using the Django ORM queryset syntax? -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/847DD166-E3C3-42D1-A10A-CDF0F19B7D75%40indx.co.uk.
Re: Need to Replace django default I'd with UUID field
It's more or less the same problem, use a new field to insert your new foreign keys (UUIDs), looking them up via your old foreign keys to get the new UUID values. Or, as the other Jason suggests, if you can, just use the UUIDs for external access. -- Clive On 22 Nov 2022, at 19:02, Rajesh Kumar wrote: Hi Jason, Thanks for a quick reply. I got your point, but I am worry about my existing data/records which is already associated with id , which is default one. On Wed, 23 Nov, 2022, 12:29 am Jason Turner, wrote: I would just add another column that holds the UUID value instead of changing the default ID. On Tue, Nov 22, 2022, 12:55 PM Rajesh Kumar wrote: Hi everyone! Hope everyone is doing well... Actually I have 100+ existing data in my database with default I'd field of django Now I need to replace that default I'd to UUID. How I can do this without loosing any records of my database. If anyone can give me suggestions that would be great. Thanks Rajesh Kumar -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/ d/msgid/django-users/CAKNDe%3D%3DEa0ZagzpZ-Y_bXKrCi3ZHdG_PNr5% 3DgxeJCTbKdM_tdA%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/ d/msgid/django-users/CADoyC17Ar%2B5aHx2GHCdqTuHJagbJx6% 3DFzj9zHP19-4-E1j6Pew%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/ d/msgid/django-users/CAKNDe%3Dks0Gc%2BR8Hs6u%3DmhtQv3PjwyxaRqF2% 3D7pwyP1NF34t5bQ%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/0DC12C1C-84CA-4102-8B05-8BA2329D3ED0%40indx.co.uk.
Re: Django model design best practice guidance
Thanks Mike, i think the lack of understanding of the underlying implementation is what was tripping me up. Data tracked by this "field" actually being a different table at the DB level makes complete sense. I have added the M2M field to my ticket model and now have this working at the DB level. For anyone who stumbles on this in the future, lets take my sudo-models below, if i add a field subscribers to ticket, as a M2M field to User, I can now add 1 or more User objects to said "field" which is actually a table, in this example appname_ticket_subscribers which i can add/remove users to with ticket.subscribers.[add/remove].(userObject). example models User: username = charfield other things Ticket: requester = fk to user owner = fk to user *subscribers = models.ManyToManyField(User) <-- the new field* other things and in the DB db=# select * from app_ticket_subscribers; id | ticket_id | user_id +---+- 1 | 01 | 1 (1 row) The relevant KB for anyone trying to implement a similar thing: https://docs.djangoproject.com/en/4.1/topics/db/examples/many_to_many/ On Thursday, December 8, 2022 at 5:02:05 PM UTC-7 Mike Dewhirst wrote: > On 9/12/2022 3:04 am, Joshua Corlin wrote: > > Ive not used this field before so if it is im having a hard time wrapping > my head around how this would work in this use case. > > > Many-to-many is simple to conceptualise if you realise it is not a field > in the table you think it is. > > It is actually a separate table containing two foreign key fields. One > points to a particular record in your target table and the other points to > a particular target record in either the same table or a different table. > > Django makes this easy by defining a many-to-many field in the model > definition but it actually uses that definition to create the separate > relationship table (the "through" table) with two foreign keys. > > The nice thing is the "through" model can also be included explicitly > among other model definitions. Doing so lets you add other fields to it > which can describe the relationship. > > It is definitely worthwhile studying the docs to get this right because it > lets you model the real world much more accurately. > > There are migration gotchas when you explicitly define models which have > already been created implicitly with Django's many-to-many field but there > are documented solutions. > > Cheers > > Mike > > -- > Signed email is an absolute defence against phishing. This email has > been signed with my private key. If you import my public key you can > automatically decrypt my signature and be sure it came from me. Just > ask and I'll send it to you. Your email software can handle signing. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/ca893628-f140-4810-8f08-ce12daaa9a9dn%40googlegroups.com.
Re: Django model design best practice guidance
On 9/12/2022 3:04 am, Joshua Corlin wrote: Ive not used this field before so if it is im having a hard time wrapping my head around how this would work in this use case. Many-to-many is simple to conceptualise if you realise it is not a field in the table you think it is. It is actually a separate table containing two foreign key fields. One points to a particular record in your target table and the other points to a particular target record in either the same table or a different table. Django makes this easy by defining a many-to-many field in the model definition but it actually uses that definition to create the separate relationship table (the "through" table) with two foreign keys. The nice thing is the "through" model can also be included explicitly among other model definitions. Doing so lets you add other fields to it which can describe the relationship. It is definitely worthwhile studying the docs to get this right because it lets you model the real world much more accurately. There are migration gotchas when you explicitly define models which have already been created implicitly with Django's many-to-many field but there are documented solutions. Cheers Mike -- Signed email is an absolute defence against phishing. This email has been signed with my private key. If you import my public key you can automatically decrypt my signature and be sure it came from me. Just ask and I'll send it to you. Your email software can handle signing. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/4ea3a261-b8cc-ff61-5e95-1fd31041b4ab%40dewhirst.com.au. OpenPGP_signature Description: OpenPGP digital signature
Django model design best practice guidance
Hello Django Community, I am working on implementing a feature in a project that I built and I am looking for some guidance on how implement the database side of this feature most efficiently. The models in question: The two models in question are the user model and a model that tracks tickets raised by users. A ticket has a requester, self explanatory, and an owner, the owner being the person who winds up getting assigned and working the ticket to action the underlying request. Both of these columns on tickets are foreign keys to user. example models User: id = auto pk username = charfield other things Ticket: id = auto pk requester = fk to user owner = fk to user other things The problem Im now trying to solve: We have a desire to be able to allow other users outside the requestor/owner to get notified in the event of a ticket being updated by either the owner or the requestor, effectively a list of subscribers. What would be the best practice for implementing a column to track 1 or more subscribers from a user model to some other model using a single column in a project like this? My initial brainstorming: I am sending notifications using logic that just requires username so I know I could just store a list of users in a charfield but ive got to imagine theres a more elegant way of doing this. Is this a use case for a manytomany field? Ive not used this field before so if it is im having a hard time wrapping my head around how this would work in this use case. Any guidance from the community on this would be greatly appreciated! -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/b50c92eb-59b7-46fc-a32a-7c5c0f0b2c01n%40googlegroups.com.
how to serialize default user model in drf serializer
Good morning, i am doing a simple interface which has a foreign to the default user model: I find some difficulties in writing the serializer as there's not serializer for the User default model. Any idea of how can i solve this? Below is my model code. Regards. AGnese Camellini from django.conf import settings class NovelUser(models.Model): novel = models.ForeignKey(Novel, on_delete=models.DO_NOTHING) user = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete= models.DO_NOTHING) -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CACXuh-SR_dgBxAKWmrxtYXgDGCT1a51sDBKgK%3D%3Dz369w%3DL6RRg%40mail.gmail.com.
