In our application we will give titles to users based on their points. So, if a user has 10-99 points, that user might get the "Novice" title, but a user with 100-199 points might get the "Regular User" title. I plan on eager loading a user's points using an attribute and relationship, and once I have those points I will use an attribute method to assign the title.
But how do I get the list of possible titles?
I could make a model, a migration, and a seed file, but I feel like these titles won't change much and certainly would never need to be updated in an API call. I could also hardcode an array of points and titles and do a quick lookup to see which title belongs to a user, but then I need to somehow deliver those titles to the user in an Attribute method. Or I could store them in a repository or the cache.
Can I access a repository from within a model? Is it better to store this sort of data in a DB anyways, regardless of how often it's updated or queried?
You could use entries in your .env file to store the entries and then use some logic in your php to select the correct .env entry.
LEVEL_1_TITLE=Novice
LEVEL_2_TITLE=Regular
...
if($user->points < 99){
$title = env('LEVEL_1_TITLE');
}
...
Or do the same thing from an array in a class that you create and just select the correct array entry based on the points.
Related
I add new users.
Let's presume we add a field of 'additionaldata1' on the parse user class
I do NOT want the user to be able to see the data stored in 'additionaldata1' and as such don't want it returned when I query the current parse users.
Seeing as the code is a web.app I don't want it to be possible for a user to 'hack' the local code in order to bring back 'all' their user object data.
So my question is how do I ensure that certain fields such as 'additionaldata1' are NEVER returned on the parse.com user object? Do I have to set up an additional class that is related to the user but set the ACL as non-read? Or can I set ACL per field on the user class?
EDIT//
UPDATE: I believe I worked this out myself. It doesn't appear to be possible to set ACL per field on a class. As such I have to add this data into an additional class with a RELATION and then set the ACL on that class table to 'no read' and 'no write'. That way only cloud code can see the class values due to the master key and I can run any validation and queries via cloud code where I need that data to be secure / private from the user.
This case is mentioned in Parse Docs under one-to-one relational data https://www.parse.com/docs/relations_guide#onetoone_anchor.
They recommend that you split up the data into two tables and use a one-to-one:
In Parse, a one-to-one relationship is great for situations where you need to split one object into two objects. These situations should be rare, but two examples include:
Limiting visibility of some user data. In this scenario, you would split the object in two, where one portion of the object contains data that is visible to other users, while the related object contains data that is private to the original user (and protected via ACLs).
Splitting up an object for size. In this scenario, your original object is greater than the 128K maximum size permitted for an object, so you decide to create a secondary object to house extra data. It is usually better to design your data model to avoid objects this large, rather than splitting them up. If you can't avoid doing so, you can also consider storing large data in a Parse File.
I am building a feature where when a person signs up for an account we will automatically populate their account with default categories and items to get them started.
Further, they can optionally purchase additional category sets to add/populate their accounts at anytime.
I am thinking my choices are:
1) Somehow use seeds.rb
2) Store these records in a YAML file and load in upon account creation
3) Store these records in the DB as a default set and clone/dup them.
Any help appreciated w/ code examples to get me started.
This is what I would do:
Have a flag in the DB to identify first_sign_in Store the data in a yaml file (e.g db/users.yml) and do:
def populate_user
user.update_attributes(YAML.load(Rails.root + 'db/users.yml')) if first_sign_in == 0
end
Then you can add this to an after_create hook so it is called only when a user is created
I'd do it differently. I'd have a "Registration" form object between the controller and model(s). Have this build some default categories and items at the same time as it first builds a user. How you isolate the attributes of those default items depends on how complex they are. If they're simple a default hash in the form object will suffice, if they're complex you can pull in from YML.
When I've done this in the past - had a signup which requires multiple object creation I've had a RegistrationsController, a RegistrationForm object which takes the params and validates everything, and is also responsible for knowing what to save, and sometimes in intermediate Registrar object (Struct usually) which has all the logic for callbacks. The registrations_controller initializes a registrar which is sent a message register(registration_form).
This leads to isolation of responsibilities and much cleaner code in the long run.
The answers provided are definite options, with which I experimented with. However, I decided to go a different route. I realized that I would need to manage these 'template' records and a DB would be easiest.
1) I setup a column on the table 'is_template' to mark the records that will be used to seed other accounts.
2) Created an after_create call back to seed the accounts using these records.
3) To make matters easier I used the amoeba gem which allows me to copy the records and their associated records which works great since some of them have has_many relationships.
This has been working great so far - and I also have a way for myself and the non-tech staff to update the records.
I installed the profile module http://orchardprofile.codeplex.com/ but I am wondering what's the best way to implement the following:
Let users track "BMI" via profile. User enters BMI (body mass index) via their profile and the values will be saved. A graph will be shown illustrating the saved values over a period of time.
This is just an example. I am wondering what's the best way to do this sort of thing...
As a supplementary question, is it possible to create a new content type and then "link" that to a particular user?
Thanks.
To store the values over time, you should probably create your own part and have it store a list of records, each of which should have a date and a BMI value. See http://docs.orchardproject.net/Documentation/Creating-1-n-and-n-n-relations for a description of the work required to establish relationships.
Linking content items can be done easily in 1.5 using the new content picker, at least for the simplest kinds of relations.
I am working on a MVC3 code first web application and after I showed the first version to my bosses, they suggested they will need a 'spare' (spare like in something that's not yet defined and we will use it just in case we will need it) attribute in the Employee model.
My intention is to find a way to give them the ability to add as many attributes to the models as they will need. Obviously I don't want them to get their hands on the code and modify it, then deploy it again (I know I didn't mention about the database, that will be another problem). I want a solution that has the ability to add new attributes 'on the fly'.
Do any of you had similar requests and if you had what solution did you find/implement?
I haven't had such a request, but I can imagine a way to get what you want.
I assume you use the Entity Framework, because of your tag.
Let's say we have a class Employee that we want to be extendable. We can give this class a dictionary of strings where the key-type is string, too. Then you can easily add more properties to every employee.
For saving this structure to the database you would need two tables. One that holds the employees and one that holds the properties. Where the properties-table has a foreign-key targeting the employee-table.
Or as suggested in this Q&A (EF Code First - Map Dictionary or custom type as an nvarchar): you can save the contents of the dictionary as XML in one column of the employee table.
This is only one suggestion and it would be nice to know how you solved this.
I'm using MongoDB w/ Sinatra for an iPhone app.
I have a users MongoDB collection and a picture GridFS collection. Each user has one picture, so, initially, I just set the ObjectId for the picture to be the same as the corresponding user. That made it easy to, given the user's ObjectId, get the picture of that user with just one query. Then, I was planning to store the MD5 hash of the picture in the user object so that the iPhone would know to download the picture only if the MD5 hash had changed. This would work, but I had to modify the Grid Ruby class to get the MD5
But then, Kyle Banker suggested that I just store the picture_id, instead of the MD5, in the user object. But, if I do that, given a user ObjectId, I'd have to first query the picture_id from the user, and then query the picture (2 queries). Is there a way, in one query, to get the picture given a user's ObjectId? Reading up on GridFS indexes, I think there's a way to store the user's ObjectId in the meta data of the picture and then set an index on that field. That way, I could do it in one query. If that's correct, what's the code look like to do that in Ruby?
Alas, should I even bother? I could just as easily use the picture_id to query the picture, which is what I'll do for now, but it'd also be nice, from a syntactical perspective, to be able to query the picture (in one indexed/fast query) by the user_id. Kinda like Facebook's graph api lets you do, e.g., http://graph.facebook.com/mattdipasquale/picture.
Sure. Like you suggest, just store the user_id somewhere in the picture's file object, and build an an index on that field.