I have a rails app where i have a Contact model and with an embedded address document so a contact can have multiple address's all stored in the one document.
I want to use backbone on the front end to have a contact page to edit contact details ie name, age and then also to add many address's.
What is the way to do this ? Should i be posting the whole contact model including all address's each time a field is changed or an address is added / removed ?
Or should i be doing pop / push atomic operations some how?
I am using mongomapper by the way.
I hope someone can explain the way this works?
thanks
rick
First, have a look at this question which discusses the full update versus the incremental update approach:
Voting system with Backbone.js
That is for a simple counter, so the $inc operator is not what you are looking for, however you can use other atomic operators (like $set), for in place updates, see here:
http://www.mongodb.org/display/DOCS/Atomic+Operations
The last thing you then will want to think about is the document size. If you allow the user to have an infinite number of addresses then be prepared to incur hits if/when the document exceeds its original size (plus some padding). That can mean more IO and updating indexes etc. A full discussion is beyond the scope of this question, but check out this page for a start:
http://www.mongodb.org/display/DOCS/Updating
Hope that helps!
Related
I've built a Rails app, basically a CRUD app for memos/notes.
A notes title must be unique. If a user enters a name already taken a warning message is shown prompting them to chose another.
My question is how to make this latency for this feedback as close to zero as possible. When creating a note little UX speed bumps like this will get annoying for user quickly.
Of course the main bottleneck is the network. Inspired by Meteor (and mini-mongo) I was thinking some kind of local storage could be a solution?
I.E. When app first loads, send ALL JSON to the client with ALL note titles. The app (front end is Angular JS) could check LocalStorage (or App Cache, Web SQL?) instead of incurring a network round trip. The feedback would be instant.
I've used LocalStorage in the past to augment an app, but in the scenario it'd really seriously depend on it. I'm not sure how confident I'd be building on something that user might not have. Also as the number of user Notes/Memos I have doubts how feasible it is to send a JSON object down the wire with ALL the note titles. That might get pretty big. On the other hand MeteorJS seems to do this with no probs.
Has anyone done something similar or have any pointers? Thanks!
I don't know how Meteor works here, but you're right that storing all note titles in localStorage is not a good idea. Actually, you don't need localStorage here, you can just put it in a JS array, because you need this data only once (when checking new note title).
I think, there could be 2 possible solutions:
You can change your business requirements and allow non-unique title. Is there really a necessity for titles to be unique?
You can verify note title when user submits form. In this case you can provide suggestions for users, so they not spend time guessing vacant title.
Or, if titles must be unique only within a user (two users can have same title for their notes), you can really load all note titles in JS array and check uniqueness while users types in a title.
Or you can send an AJAX request checking title uniqueness as soon as user finished typing the title. In this case you can win some seconds.
Or you can send an AJAX request as soon as user typed in 3 symbols. The request will return all titles that begin with these 3 symbols, so you don't need to load all the titles.
I am not sure what is better perfomance whise so I ask you guys.
The problem is following:
I have a system where each User gets a certain amount of credit for certain events. So I gave my User an attribute named creditscore that gets altered on those events. Everything works well. But now I want the user to actually see what he did when and how much credit he got for this.
What would be better here:
Saving the whole history in a text attribute and add lines for each event
or
writing an extra model associated with the user and create an instance for every event.
or
or
something way different?
Since there are several events per user per day it would be either a huge text or a huge amount of instances. What would be better looking at website performance.
You absolutely do NOT want to store the history in a text attribute. Management of this will be a nightmare as will querying the data.
You could create a CreditEvent model and store the individual events in there. That would work fine.
However, before you start, check rubygems.org and ruby-toolbox.com to see if someone has already done the hard work. I know of at least one gem that seems to do exactly what you want to do:
https://github.com/merit-gem/merit
Apologies in advance as I'm sure this topic has no doubt been asked before but I couldn't find any post that answers my specific query.
Bearing in mind that I'm new to MVC this is where I have got to. I've got a project developed under VS 2010 using the MVC 3 framework. I've got a search page which consists of 6 fields and a nested model which itself holds around 3 fields.
I can successfully post all this data back to itself and the data is successfully passed as a model and back agian so the fields keep the data which the user has supplied.
Before I move on to actually using this search criteria on another view a thought hit me. I want to keep this search criteria, and possibly even the search results in memory for the duration of the users session.
The reasoning behind this is simply to save my users time by:
a) negating the need to keep re-inputting their search criteria regardless of how they enter or leave the search page
b) speed up the user experience by presenting the search results more quickly
The later isn't as important as the first requirement.
I've done some google searches and indeed had a look through this site on similar topics. From what I've read using sessions (which I would typically use if developing a PHP site) is a no no. From the reasons I've read as to why you shouldn't use sessions seem valid and I'm happy to go along with it.
But now I'm left in a place where I'm scratching my head wondering to myself what exactly is best practice to achieve this simple goal that could be applied to similar situations later down the line in the project.
I also looked at the OutputCache method and that didn't behave as I expected it to. In a test I set the timeout for 30 seconds. After submitting a search I clicked the link to my search page to see if the fields would auto-populate, they didn't. But then clicking the search button the values in the cache were retrieved. I thought I was making progress but when I tried to submit a new value the old value from the cache came back i.e. I couldn't actually change my search criteria with the cache enforced. So I've discounted this as an avenue to explore.
The last option seems to suggest the use of cookies as the most likely candidate, but rightly or wrongly I feel this isn't the best solution. I would have thought the MVC 3 design pattern would have an easier and recommended method of persisting values. I'm sure there is but I've just not discovered it yet.
I have started to use JQuery and again this has been mentioned but I'm not sure this is right direction to take either.
So in summary my question really comes down to what is considered by the wider community as best practice for persisting data in my situation. Effiency, scalability and resiliancy is paramount as I'll have a large global user base that will end up using this web app.
Thanks in advance!
Pete
I'd just use cookies. They're simple to use, you can persist them for as long as you want or have them expire when the users closes their browser, and it doesn't sound like you are storing anything sensitive in them.
Sorry for the simple question but I've searched through the forums for 2 hours.
Goal:
I want to track my websites URLs across the web. I'm current using google analytical to do tracking which is fine for me. But I want to show my users where their links are being clicked when they login to their account.
What's the best way I can do this? I'm using a php backed if that helps. My goal is to provide: how many times their links are clicked and where the URL was clicked from.
Edit: I was hoping somebody else would give you a better hint, but since the question doesn't seem to attract many people I'll try to give you a better answer.
So, breaking down your problem to pieces, you want to trigger a piece of code everytime a page is accessed. You should be able to do a mapping between the page and its owner at one point - when rendering the statistics. If you want to "cut corners" and have a simple solution, you simply insert into your database a new entry describing the event. You seem to be only interested in the number of times it was accessed, so for a specific pageID, you can count how many entries there is, so this data can be computed directly from your database.
Now, the interesting part, figuring out where the visitor comes from. If you take a look at the $_SERVER variable for PHP, documented here, you will see that it contains a lot of interesting information. I think you're mostly interested in 'HTTP_REFERER' which contains
The address of the page (if any) which referred the user agent to the
current page. This is set by the user agent. Not all user agents will
set this, and some provide the ability to modify HTTP_REFERER as a
feature. In short, it cannot really be trusted.
Looking quickly on Stack Overflow I didn't find a more trustable source, so when available, I guess that's the only data you can use.
If you want to make things a bit more robust, you could log the IP address of the visitor and only count 1 visit per day.
So, to recapitulate, you create a table which logs the visits, containing the pageID and referer (optionally the IP address and date to prevent multiple insertions on the same day from the same user if you want to be strict). You add a function call to each page that will record the information of your pageID, maybe the URL or an ID you use internally? and the value of $_SERVER['HTTP_REFERER']. Then, when a user wants to see his stats, you look up every pageID that belongs to him, then pull the count of entries for that page and all the referers.
I hope my explanations are clear. It's definitely not bulletproof, but it's simple and should do the job, and it can be programmed pretty quickly.
Old answer: Piwik (documented here) is pretty similar to Google Analytics. Since you own the database where the data is stored, you could probably extract all the data you want, the way you want it, and manipulate it the way you want without having to depend on someone else (Google).
I'm developing a webapp that allows the editing of records. There is a possibility that two users could be working on the same screen at a time and I want to minimise the damage done, if they both click save.
If User1 requests the page and then makes changes to the Address, Telephone and Contact Details, but before he clicks Save, User2 requests the same page.
User1 then clicks save and the whole model is updated using TryUpdateModel(), if User2 simply appends some detail to the Notes field, when he saves, the TryUpdateModel() method will overwrite the new details User1 saved, with the old details.
I've considered storing the original values for all the model's properties in a hidden form field, and then writing a custom TryUpdateModel to only update the properties that have changed, but this feels a little too like the Viewstate we've all been more than happy to leave behind by moving to MVC.
Is there a pattern for dealing with this problem that I'm not aware of?
How would you handle it?
Update: In answer to the comments below, I'm using Entity Framework.
Anthony
Unless you have any particular requirements for what happens in this case (e.g. lock the record, which of course requires some functionality to undo the lock in the event that the user decides not to make a change) I'd suggest the normal approach is an optimistic lock:
Each update you perform should check that the record hasn't changed in the meantime.
So:
Put an integer "version" property or a guid / rowversion on the record.
Ensure this is contained in a hidden field in the html and is therefore returned with any submit;
When you perform the update, ensure that the (database) record's version/guid/rowversion still matches the value that was in the hidden field [and add 1 to the "version" integer when you do the update if you've decided to go with that manual approach.]
A similar approach is obviously to use a date/time stamp on the record, but don't do that because, to within the accuracy of your system clock, it's flawed.
[I suggest you'll find fuller explanations of the whole approach elsewhere. Certainly if you were to google for information on NHibernate's Version functionality...]
Locking modification of a page while one user is working on it is an option. This is done in some wiki software like dokuwiki. In that case it will usually use some javascript to free the lock after 5-10 minutes of inactivity so others can update it.
Another option might be storing all revisions in a database so when two users submit, both copies are saved and still exist. From there on, all you'd need to do is merge the two.
You usually don't handle this. If two users happen to edit a document at the same time and commit their updates, one of them wins and the other looses.
Resources lockout can be done with stateful desktop applications, but with web applications any lockout scheme you try to implement may only minimize the damage but not prevent it.
Don't try to write an absolutely perfect and secure application. It's already good as it is. Just use it, probably the situation won't come up at all.
If you use LINQ to SQL as your ORM it can handle the issues around changed values using the conflicts collection. However, essentially I'd agree with Mastermind's comment.