I have 5 types of objects in an application let's say A, B , C, D, E
The application lists objects of all type, where it shows their name, created user and other Info.
Now, to be able to show user's name in every object listing, I have some options
1) Store the USER entity key in every object and then when I retrieve say list of Objects of type A, then also retrieve user's keys and their names and then attach them to objects of type A
2) When a object of any type is created, also store a property "Name" which will be name of user who created the object (Yikes approach IMHO, what if the user changes his name later ;)
But I am not convinced both ways above are right! I am looking for an answer, from someone who might have faced similar problem
Actually you've already answered yourself, option 2 is not advisable, since an user can change his/her username, and cascading the change (manually) in the DataStore is not a good choice.
http://code.google.com/appengine/docs/python/datastore/typesandpropertyclasses.html#ReferenceProperty
Example from the link:
class Author(db.Model):
name = db.StringProperty()
class Story(db.Model):
author = db.ReferenceProperty(Author)
story = db.get(story_key)
author_name = story.author.name
author = db.get(author_key)
stories_by_author = author.story_set.get()
The option1 can be done easily with ReferenceProperty.
No extra code needed if the performance is not your major concern.
I haven't use java on Google App Engine,
but google app engine did support object relationship you needed as well.
http://code.google.com/appengine/docs/java/datastore/jdo/relationships.html#Owned_One_to_One_Relationships
Related
I have an Authors App which has x amount of authors. I have another app and have configured an Field Input-Type entity-query in it which pulls from the Authors App. It does this correctly and I can select multiple authors. However upon save, when I go to retrieve a content item which should contain the selected authors, I am given "empty slot" for the place of each author
Real entity fields are Entity relations, and they enforce validity. So they only work with entities in the same app, as that's kind of a sealed scope. This is important that Apps can ensure export/import and still work for all standard use cases.
To reference entities of another app you must use strings instead. This can be done using the string-query field which has the same functionality.
The only downside is that your code will need to then look up the entity in the other app using the id or guid (whichever you store) in Razor.
So I got the tables you can see in the image below:
.
What I would like to do is to create a relationship so that each user (of django auth_user) will be enrolled(or able to enrol) to exactly one "course" so that he will be able to see next events for his modules.
Do I have to create another table and place 2 foreign keys or this is a way to do it in 'php' and it's more simple with Django? I was suggested to create 'student' model inheriting from 'User' with extended behavior and one to many relationship on auth. I tried to do that but unfortunately had not results since I'm really new to Django & Python.
If every auth_user (or auth.User) will be or have the opportunity to be enrolled on a course I would create a 'user profile' model that has a 1-to-1 relationship with the django User model. You can store additional User data in this model, including what course they are enrolled on. See https://docs.djangoproject.com/en/dev/topics/auth/customizing/#extending-the-existing-user-model for more details but here is an example:
class UserProfile(models.Model):
user = models.OneToOneField('auth.User')
course = models.ForeignKey('courseapp.Course', null=True)
You would probably need to create a signal that gets fired each time an auth.User object is saved, such that if it is the first time that User object has been saved, it automatically creates the UserProfile:
from django.contrib.auth.models import User
from django.db.models.signals import post_save
from yourusersapp.models import UserProfile
def create_user_profile(sender, instance, created, **kwargs):
# Automatically creates a UserProfile on User creation.
if created:
UserProfile.objects.create(user=instance)
post_save.connect(create_user_profile, sender=User)
When you query a User object, you can then reference the User object's profile like:
user_object.userprofile
You could then create a Course object and link the user_object indirectly via its UserProfile to that Course:
course = Course.objects.create(name='course_name', next_field='whatever')
user_profile = user_object.userprofile
userprofile.course = course
userprofile.save()
Now you have a user object with a UserProfile that is linked to only 1 course. Many users can be on the same course, but a user can only be on 1 course. You can also reference all users on a particular course like:
course = Course.objects.get(name='course_name')
course_users = course.userprofile_set.all()
HTH
I think that you can go about this one of two ways.
Extend the User model. 'Student' would probably be a good name for your new model. It would have a OneToOne relationship with 'User', and a ForeignKey relationship with 'Course'. It can store any other information that is applicable to students only. Documentation for how to do that can be found here https://docs.djangoproject.com/en/1.6/topics/auth/customizing/#extending-the-existing-user-model
Create a custom User model that has a ForeignKey relationship with Course. This approach is a bit more complicated, but yields a slightly cleaner end result. Documentation for that is here. https://docs.djangoproject.com/en/1.6/topics/auth/customizing/#substituting-a-custom-user-model
Sorry if it seems like I'm just sending you to the Django docs, but both of those sections are well written and should explain things pretty clearly. If you'd like to post another question with example code we can try and see why your original attempt at extending the User model didn't work. By the way, your "Student" model shouldn't have to inherit from the User model in order to extend it.
I have an Entry model as follows:
class Entry(models.Model):
date_posted = models.DateTimeField(auto_now_add=True)
last_edited = models.DateTimeField(auto_now=True)
author = models.ForeignKey(CustomUser)
title = models.CharField(max_length=150)
description = models.TextField()
tags = models.ManyToManyField(tags)
Now, whenever a user creates or edits an Entry object we send it to the moderation queue and the object is not available to the default manager for Entry object until it has been moderated. It makes sense when a user is initially creating an object but when a user is edit the entry object it disappears from the search results. We also offer users to save or bookmark, different entries. so the edited Entry object is not available in the saved entries anymore until it has been moderated.
What I am looking to do is to have the old Entry show up until the edited Entry is under moderation once the edited entry object is moderated we can replace the edited entry with the original one.
One way I can think of is to create a different Entry Object for each edit a user makes but I am not quite sure if that is a feasible and a sensible approach to handle this situation wouldn't it just have a lot of duplicate data in the database ??
Questions:
what are my options ? (I would also like to know which ones would be the best performance-wise)
Is there a way I can achieve this without duplicating the object ?
In my opinion, if the number of objects that are sent to the moderation queue is low to moderate, you can have a ManyToMany (Infact a One to Many is what you want) field which keeps references to the versions from the Entry object.
If this is not feasible, you can look into django-pickle-field which lets you store any object types into the database. So, you can create an additional nullable column, in which you would save the form data on edit as-is and make it available in the moderation queue.
So, the logic for moderation queue is something like:
MyObject.objects.filter(pickle_field__isnull=False)
Once the moderator approves, override the field data into the object.
else, discard the picklefield.
If you want to allow multiple edits, or keep track of moderation history, you can make that a ManyToMany with more info (such as edited by, moderated by, etc.) in the intermediary table.
I'm quite new with Django, and so far I have a pretty basic setup where I attach an extra model to the default User model from (django.contrib.auth.models). In my accounts.models.py I have something in the line of:
class UserExtension(models.Model):
user = models.OneToOneField(User, primary_key=True)
# more code
I also have another model which needs to be specified an owner. My question is: Which is the better (more django-ish, more readable, more efficient, more flexible) way to signify the owner:
class Owned(models.Model):
# code
owner = models.ForeignKey(User)
# more code
or:
class Owned(models.Model)
# code
owner = models.ForeignKey(UserExtension)
# more code
I'll really appreciate if you mention pros and cons of those approaches.
I'd recommend the first option. The user model is the nontrivial model in the sense that an owned object should not be able to exist without a user, but could exist without a UserExtension.
Also consider that in Django 1.5 you are able to create custom user model, eliminating the need for the UserExtension class. See the documentation for more information.
Consider using UserProfile for any per user add-on information. Check out this blog to see how to do it. Then you can be assured that you are creating UserProfile object every time you create the User.
Now whether you FK on User or UserProfile depends logically on what you are doing within Owned. If Owned works with User's data/field, FK on User; if it works with UserProfile's data, FK on UserProfile.
I have a simple Post model in my django app:
class Post(models.Model):
category = models.CharField(max_length=10, choices=choices)
message = models.CharField(max_length=500)
user = models.ForeignKey(User, editable=False)
I'd like to implement the feature of having anonymous users create posts with nick names. Unfortunately django doesn't allow you to save an instance of AnonymousUser as a foreignkey to the Post class.
I was thinking of adding a "dummy" user record into the db that represents the anonymous user(id=0, or some negative number if possible) that would be used for all posts without a user. And if it is present a nullable name field would be used to represent the nickname of the anonymous user.
This solution seems a bit hacky to me. Is there any cleaner more effecient solution?
If you can identify new users by some session information, you could just create normal user accounts, pro forma so to speak - with a flag to identify them as volatile (this may lead to some regular maintenance cleanup).
If, during session lifetime, the user actually want to register, you can reuse the user account on your side and the user can keep all his data on his.
As #slacy commented and #Dominique answered; instead of rolling your own take a look at existing projects, e.g. this:
http://www.stereoplex.com/blog/introducing-django-lazysignup
Not tested , but this can help:
https://github.com/danfairs/django-lazysignup
You can add blank=True and null=True to User ForeignKey and set it to None, if user is anonymous. You just need to store the nickname somewhere.
I am new to Django. A friend told me not to use ForeignKey further stating that using CharField is ok. ForeignKey is slower than CharField, as it has some check for user info.