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.
Related
This is a design question.
I'm trying to build a booking system in cakephp3.
I've never done something like this with cake before.
I thought the best way might be to -- as the post title suggests -- build up an entity over several forms/actions.
Something like choose location -> enter customer details -> enter special requirements -> review full details and pay
So each of those stages becomes an action within my booking controller. The view for each action submits its content to the next action in the chain, and i use patch entity with the request data, and send the result to the new action's view.
I've started to wonder if this is a good way to do it. One significant problem is that the data from each of the previous actions has to be stored in hidden fields so that it can be resubmitted with the new data from the current action.
I want the data from previous actions to be visible in a read only fashion so I've used the entity that i pass to the view to fill an HTML table. That's nice and it works fine but having to also store that same data in hidden fields is not a very nice way to do it.
I hope this is making sense!
Anyway, I thought I'd post on here for some design guidance as i feel like there is probably a better way to do this. I have considered creating temporary records in the database and just passing the id but i was hoping I wouldn't have to.
Any advice here would be very much appreciated.
Cheers.
I would just store the entity in the DB and then proceed with your other views, getting data from the DB. Pseudo:
public function chooseLocation() {
$ent = new Entitiy();
patchEntity($ent,$this->request->data);
if save entity {
redirect to enterCustomerDetails($ent[id]);
}
}
public function enterCustomerDetails($id) {
$ent = $this->Modelname->get($id);
// patch, save, redirect again ...
}
In my web application, there are several classes whose instances need an image (i.e., photo). Each of these instances can have only one image. Currently, my implementation is that when user creates a new instance, I keep the name of the uploaded file as it is, and record it in the ImageUrl field of the associated table.
I feel like this is unnecessary. I can just rename the image with the unique url of the associated instance, and I can implement the programming logic accordingly. For example, if a user's id is 145, then I can record it with this name: profilephoto_145. Later, when I need to display the user's photo, all I need will be the id of the user. If user uploads a new file, I can just overwrite the existing file with the same name.
I wonder if this makes sense assuming each instance will have one associated image, and there will be no need to keep track of the previous files. What is the common approach for this? Should I keep the full path for each image and keep their original names, or should I implement this renaming files with ID?
I can just rename the image with the unique url of the associated
instance, and I can implement the programming logic accordingly. For
example, if a user's id is 145, then I can record it with this name:
profilephoto_145.
Yes, you can do that. The general search term for this kind of thing is "tight coupling" or "coupling and cohesion". The concept applies in lots of different areas of software development.
Your underlying idea is that you'll always store one profile photo per user, and you'll store it by concatenating "some kind of path" and "profilephoto_" and user's id. The main problem is that any change to that idea requires changing source code. And changing source code has ripple effects.
The common alternative is to store the image file's name in a database. In this case, most changes to that underlying idea would require only a database update.
Programmers who have been around a while cringe a little when people start using words like always and never. Because we know that, given enough time, statements that use always and never with respect to software are always never true.
I have a store and a model with a hasMany association.
If I call Ext.getStore('SessionStore').removeAll() does it also remove any associated data with the records in the store?
If not, how would I do this?
if you console log a record in SessionStore you should have a property with the name of the association plus the suffix Store
e.g. if the name of the association is personalInformation there should be a new property in the record called personalInformationStore.
So the answer would be yes by removing a record or all from a store the associated data will also be removed as this data is part of the parent object.
Perhaps Ext.StoreManager.getCount() can help validate the existence of the data / objects.
I also recommend this chrome extension: https://chrome.google.com/webstore/detail/app-inspector-for-sencha/pbeapidedgdpniokbedbfbaacglkceae?hl=en
For the contacts object, I have a custom checkbox which represents whether the contact owner wants the contact information (email and phone) to be visible. Most of our contacts will be completely visible to everyone. However, for a few contacts, we want them to be visible but their contact information needs to be hidden to everyone except for the owner.
Is there a way to set field-level access dependent on another variable? Could you create a workflow to redirect to another page layout if the contact information is visible? If so, can you restrict objects to certain field layouts depending on whether or not you are the record owner? And would would the contact information for "hidden contacts" still show up in reports?
Redirects, custom Visualforce view page etc hacks are all nice and shiny until you realize people will be able to pull data they want via some reports, list views, Outlook integration, mobile apps etc ;)
There's no straightforward answer because field visibility is really "all or nothing" (by Profiles & Permission Sets). Owner/Role-related stuff will help you only if you'd store data in some new related objects.
Another option - Store public part in Leads (public read only for example) and sensitive part - in Contacts (private)? Some lookup to link the 2, maybe a trigger when new Contact is created and you're good to go.
Last but not least - have a look at https://salesforce.stackexchange.com/questions/777/can-i-grant-different-field-level-security-based-on-record-ownership for some ideas.
If I understood correctly (My english...) You could create a new RecordType and a new customized page layout without this fields assigned to it, then you have to create a WFR that change the Recordtype when the cheked field becomes true.
I'm assuming that you know how you have to give permissions to this new Recordtype...etc
Hope this helps.
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