I have rails app witch collect mobile data and use elastic search as search engine in my app, As result that my app is very simple I use elastic as my db, every things goes fine till I found something amazing
In my case each user have two kind of document with different attributes, First one is profile that it's about user profile only and Second one is events that is user actions in mobile app. I have to say، user could update his/her profile and each user just have to one document in my system, that is about profile details. each time user update his profile I delete previous document and create new document for him but assume he send profile twice at same time unconsciously for example push register bottom twice at this point i get two document that are completely same so elastic save both but as i say i need to delete old one and create new one, I know I could handle this problem in mobile layer but I'm looking for some way witch make me sure at this situation document have their priorities.
Basically you need a versioning of your documents and using that you can control whether you need to create a new document or update existing document. this official Elasticsearch version control blog should help you design and implement this use-case.
I really hope I got your point correctly, consider the following points
prevent users from submitting twice in your front end.
update the document instead of deleting the previous one then creates a new document so that you don't have to worry about document priorities because of a single file.
Related
TL;DR: I want to add images to the app over the internet through background downloading of some sort, but don't know where to start, or what the best method is.
My app displays images to the users which can be filtered etc. I have a "Cards" class that has fields for name, image, etc. I then have a huge area directly in my code where I create instances of the Cards class for each image. There is then an array of these class instances, which helps with displaying them.
My issue is that now I want to be able to update this block of class instances without having to push another build to the iTunes store. Essentially, I want to add "Cards" to the app (images with appropriate names and keywords associated with them). I need to be able to update the app every month (sometimes less) with new cards as quickly as possible.
I have heard suggestions here and there about JSON files and background downloading, but can't figure out which method I need for my situation.
As per my understanding you just want to update your app content in future without uploading a new build to App Store. Right ?
If you want to do so, make your app so flexible that you can show updated contents in your app.
Here is a short instruction which you can follow...
Develop an admin panel if you are aware of any backend scripting language like php. And you can add contents from this panel into your database.
Create an API which will fetch the content from your database
Make your app flexible so that it can show all the updated content getting from the API. If you have a list of content then you can use TableView/CollectionView with pagination.
If you still face any problem then let me know. I will see deep into your problem.
In the Simperium documentation/help section there is the following text:
All the data that is created seems like it must be tied to a user - is
that correct? Is it possible to have data that isn't tied to a user -
say a database of locations or beers?
Yes, though this isn't very clear yet. You can create a public user
(i.e., a public namespace) with an access token you share with other
users of your app so anyone can read/write to that namespace.
It's possible to limit this to read-only access as well if you need to
authoritatively publish data from a backend service.
Is there an actual example with this?
The scenario I have is as follows
My app will have a calendar
The primary user can add and remove data from the calendar
They will want to invite other users to add and remove data, my thought is that they can give them a token, the user can use their email address and this token to sign in
Am I on the right track?
You're definitely on the right track, but a little too far ahead on that track. The scenario you described is a great fit for Simperium, but sharing and collaboration features aren't yet released.
The help text you quoted is for authoritatively pushing content, for example from a custom backend to all users of your app. An example of this would be a news stream that updates on all clients as new content is added.
This is quite different than sharing calendar data among a group of users who have different access permissions, which is actually a better use of Simperium's strengths. We have a solution for this that we've tested internally, but we're using what we've learned to build a better version of it that will be more scalable for production use.
There's no timeline for this yet, but you'll see it announced on your dashboard at simperium.com.
I need to add a User Manual for my App, although all the user manual examples I have seen are web-based, which is convienent because it allows you to update the documentation without updating the app but also inconvient if the user is in a off-line mode.
What I envision in a helpful usermanual would be a popovercontroller that would display relevant data to whatever the current view has. It would retrieve documentation from the web and save it for later reference. Maybe even something that could take a document and break it into a plist by tag. Including gaphics would be nice also.
Are there any frameworks do to this available? ..... Or am I going to have to write my own.
How have other people implemented user manuals?
I am using embedded documents in MongoDB for a Rails 3 app. I like that I can use embedded documents and the values are all returned with one query and there is less load on the database server. But what happens if I want my users to be able to update properties that really should be shared across documents. Is this sort of operation feasible with MongoDB or would I be better off using normal id based relations? If ID based relations are the way to go would it affect performance to a great degree?
If you need to know anything else about the application or data I would be happy to let you know what I am working with.
Document that has many properties that all documents share.
Person
name: string
description: string
Document that wants to use these properties:
Post
(references many people)
body: string
This all depends on what are you going to do with your Person model later. I know of at least one working example (blog using MongoDB) where its developer keeps user data inside comments they make and uses one collection for the entire blog. Well, ok, he uses second one for his "tag cloud" :) He just doesn't need to keep centralized list of all commenters, he doesn't care. His blog contains consolidated data from all his previous sites/blogs?, almost 6000 posts total. Posts contain comments, comments contain users, users have emails, he got "subscribe to comments" option for every user who comments some post, authorization is handled by the external OpenID service aggregator (Loginza), he keeps user email got from Loginza response and their "login token" in their cookies. So the functionality is pretty good.
So, the real question is - what are you going to do with your Users later? If really feel like you need a separate collection (you're going to let users have centralized control panels, have site-based registration, you're going to make user-centristic features and so on), make it separate. If not - keep it simple and have fun :)
It depends on what user info you want to share acrross documents. Lets say if you have user and user have emails. Does not make sence to move emails into separate collection since will be not more that 10, 20, 100 emails per user. But if user say have some big related information that always growing, like blog posts then make sence to move it into separate collection.
So answer depend on user document structure. If you show your user document structure and what you planning to move into separate collection i will help you make decision.
I'm just starting to learn ASP.NET MVC and I'd like to know how I can retain model objects between subsequent requests to controller action methods?
For example say I'm creating a contact list web app. Users can create, update, rename, and delete contacts in their list. However, I also want users to be able to upload a contact list exported from other programs. Yet I don't want to just automatically add all the contacts in the uploaded file I want to give the user a secondary form where they can pick which uploaded contacts should be actualy added to their list.
So first I have a ContactController.Upload() method which shows an upload form. This submits to ContactController.Upload(HttpPostedFileBase file) which reads the file that was posted into a set of Contact model objects. Then I want to display a list of all the names of the contacts in the list and allow the user to select those that should be added to their contact list. This might be a long list that needs to be split up into multiple pages, and I might also want to allow the user to edit the details of the contacts before they are actually added to their contact list.
Where should I save the model objects between when a user uploads a file and when they finally submit the specific contacts they want? I'd rather not immediately load all the uploaded contacts into the back end database, as the user may end up only selecting a handful to actually add. Then the rest would need to be deleted. Also I would have to account for the case when a user uploads a file, but never actually completes the upload.
From what I understand an instance of a controller only lasts for one request. So should I create a static property on my Contact controller that contains all the latest uploaded contact model object collections? And then have some process that periodically checks the age of these collections and clears out any that are older then some specified expiration time?
A static property on the controller is trouble. First off, it won't work in a web farm and second it you'd have to deal with multiple requests from different users. If you really don't want to use your database you could use the ASP.NET Session.
No, you don't want a static property, as that would be static to all instances of the controller, even for other users.
Instead, you should create a table used to upload the data to. This table would be used as an intermediary between when the user uploads the data, and completes the process. Upon completion, you copy the contacts you want to keep into your permanent table, then delete the temporary data. You can then run a process every so often that purges incomplete data that is older than a specified time limit.
You could also use the HttpContext.Cache, which supports expiration (and sliding expiration) out-of-the box.
Alternatively, and perhaps even better (but more work) you could use cookies and have the user modify the data using javascript in her browser before finally posting it to you.
However, I'd strongly recommend to store the uploaded information in the database instead.
As you pointed out, it might be a lot of data and the user might want to edit it before clicking 'confirm'. What happens if the user's machine (or browser) crashes or she has to leave urgently?
Depending on the way you store the data the data in this scenario will probably be lost. Even if you used the user id as a cache key, a server restart, cache expiration or cache overflow would cause data loss.
The best solution is probably a combination of database and cookie storage where the DB keeps the information in a temporary collection. Every n minutes, or upon pagination, the modified data is sent to the server and updated in the DB.
The problem with storing the data in session or memory is what happens if the user uploads 50k contacts or more. You then have a very large data set in memory to deal with which depending on your platform may effect application performance.
If this is never going to be an issue and the size of the imported contacts list is manageable you can use either the session or cache to store the dataset for further modifications. Just remember to clear it when the user has committed the changes, you don't want a few heavy datasets hanging around in session.
If you store the dataset in session using your application controller then it will be available to all controllers while it is needed.