I'm making an app that are retrieving messages as PFObjects with Parse, and I retrieve these messages in my viewDidLoad-function. The problem is that this function retrieves the messages every time the page is loaded.
So I thought about making a list in my core data where I save all the id's of my already retrieved objects, and then compare the id of the newest(and possibly already retrieved) object that is being retrieved to the ones in this list.
Because I don't wanna use core data unnecessary, I was just wondering if anyone had a other and more efficient solution to this problem.
Any suggestions would be highly appreciated.
Related
We're experimenting with storing data to a MongoDB by using node-red. As it is now, we can store data on the database, but it seems like only the 'msg.payload' is stored (as document) - and not the whole msg object. Which confuses us a little...
The flow is very simple and nothing much has really been done.
We actually dont need ALL data, but we wish to store payload but also metadata as a document to our collection on our database. We've tried searching for an answer to this, but couldn't find anything relevant on how to do this. Hopefully we can get some help on this forum.
Thanks in advance! (btw. we're using mongodb3 on node-red to store data)
The node you are using is working as intended.
The normal pattern for Node-RED is that the focus of any given node is the msg.payload entry, any other msg properties are considered to be meta data.
The simplest thing here would be to use the built in core change node to move the other fields you are interested in to be properties of the msg.payload object.
I am using Sitecore 8.1 with xDB enabled (MongoDB). I would like to store the user-roles of the visiting users in the xDB, so I can aggregate on these data in my reports. These roles can change over time, so one user could have one set of roles at some point in time and another set of roles at a later time.
I could go and store these user-roles as custom facets on the Contact entity, but as they may change for a user from visit to visit, I will loose historical data if I update the data in the facet every time the user log in (fx. I will not be able to tell which roles a given user had, at some given visit).
Instead, I could create a custom IElement for my facet data, and store the roles along with a timestamp saying when the given roles were registered, but this model may be hard to handle during the reporting phase, where I would need to connect the interaction data with the role-data based on timestamps every time I generate a report.
Is it possible to store these custom data in the xDB in something else than the Contact collection? Can I store custom data in the Interactions collection? There is a property called Tracker.Current.Session.Interaction.CustomValues which sounds like what I need, but if I store data here, will I be able to perform proper aggregation/reporting on the data? Any other approaches I haven't thought about?
CustomValues
Yes, the CustomValues dictionary is what I would use in your case. This dictionary will get serialized to MongoDB as a nested document of every interaction (unless the dictionary is empty).
Also note that, since CustomValues is a member of the base class Sitecore.Analytics.Model.Entity, this dictionary is available in many other data classes of xDB. For example, you can store custom values in PageData and PageEventData objects.
Since CustomValues takes an object of any class, your custom data class needs some extra things for it to be successfully saved to and subsequently loaded from MongoDB:
It has to be marked as [Serializable].
It needs to be registered in the MongoDB driver like this:
using Sitecore.Analytics.Data.DataAccess.MongoDb;
// [...]
MongoDbObjectMapper.Instance.RegisterModelExtension<YourCustomClassName>();
This needs to be done only once per application lifetime - for example, in an initialize pipeline processor.
Your own storage
Of course, you don't have to use Sitecore's API to store your custom data. So the alternative would be to manually save data to a custom MongoDB collection or an SQL table. You can then read that data in your aggregation processor, finding it by the ID of currently processed interaction.
The benefit of this approach is that you can decide where and how your data is stored. The downside is extra work of implementing and maintaining this data storage.
TL;DR
What's the best way to handle dependency between types of data that is loaded asynchronously from different backend endpoints?
Problem
My app fetches data from a backend, for each entity I have an endpoint to fetch all instances.
For example api.myserver.com/v1/users for User model and api.myserver.com/v1/things for Thing model.
This data is parsed and placed into data store objects (e.g. UserDataStore and ThingDataStore) that serve these models to the rest of the app.
Question
What should I do if the data that comes from /things depends on data that comes from /users and the fetch operations are async. In my case /things returns the id of a user that created them. This means that if /things returns before /users, then I won't have enough data to create the Thing model.
Options
Have /things return also relevant /users data nested.
This is bad because:
I'll then have multiple model instances User for the same actual user - one that came from /users and one that came nested in /things.
Increases the total payload size transferred.
In a system with some permission policy, data that is returned for /users can be different to /things, and then it'll allow partially populated models to be in the app.
Create an operational dependency between the two data stores, so that ThingsDataStore will have to wait for UserDataStore to be populated before it attempts to load its own data.
This is also bad because:
Design-wise this dependency is not welcome.
Operational-wise, it will very quickly become complicated once you throw in another data stores (e.g. dependency cycles, etc).
What is the best solution for my problem and in general?
This is obviously not platform / language dependent.
I see two possible solutions:
Late initialization of UserDataStore in ThingDataStore. You will have to allow for creation an object that is not fully valid. And you will also need to add method that will give you an information whether UserDataStore is initialized or not. Not perfect, because for some time there will exists an invalid instance.
Create some kind of proxy or maybe a buider object for ThingDataStore that will hold all information about particular thing and will create ThingDataStore object as soon as UserDataStore related with this instance will be received.
Maybe it will help you. Good luck!
I am to a fair degree familiar with Sails and Waterline.
Situation:
We have a Model Playlist with a many-to-many association to the Model Song on sails-mongo.
When we query for all playlists, we do not want to sideload all associated songs, we just need the ids of the associated songs so that we can load them lazily later.
When we do a populate (with Ember blueprints: populateEach()) we of course get the ids, but it takes around 1s for loading all the Playlists.
Without populate it is just around 50ms.
Complication:
After getting the results with query.exec WITHOUT populate, the ids of the associated songs are not included and not sent back to the requester.
But I can log the ids of associated records to the console via iterating over Object.keys(matchingRecord).
I can set them to a new property of the matchingRecord, all without populating.
However, I cannot explicitly set them to their property name.
Using the original property name is required for the interaction with the Ember frontend.
I tried to mess around with Object.defineProperty - no success. I guess the set/get functions are overwritten to prevent that.
Questions:
How can I make those id arrays of visible/prevent that they are hidden/removed?
Are there any other ideas from your side to maneuver around this issue?
Thank you,
Manuel
When I creating same type objects and save them into database, should I send a list of that objects in one request or should I send individually for each one?
For example, I would like to create a todo list, I can create multiple todos, then click save to send a list of todos, or when I finish editing one todo, I save it directly.
The first way can save request numbers, only one request needed to create many objects. But is the first way RESTful? All infomation about create in REST is creating a single object, but will there be poblems if increasing requests numbers?
----Edit
Thank you guys answering me.
For a more spicific usecase, I am using Django Rest Framework. I created a Todo model and a corresponding serializer. I am wondering, how could I create a list of Todos? I tried to send a list of Todos to serializer, and expecting serializer can automatically loop through it as same as getting a list of instance. But that doesn't work. I know I may be able to create a loop to call create method everytime. But is there a better way to do it?
There is nothing in REST that tells you what kind of payload you are allowed to use. You can POST/PUT whatever you want - one entity representation or many representations, in lists, dictionaries, XML, URL-encoded key/values or JSON, what ever suits your use case best.
In your case you might even want to send a delta/diff list of changes on the client: Lets for instance say your client loads some existing 3 todo items. Then the user modifies one of them, deletes another one and adds a new one. You can either do that in three requests or one single request with add/modify/delete operations encoded in it. Both ways are valid and the best solution depends on your use case and constraints like bandwidth, processing power and network round-trip time.