I have seen a demo on how to use ordered lists in MDriven but I can not find it on the wiki? Is it deprecated or am I just looking in the wrong place? The need is to show an strictly ordered list, enabling the user to move items up and down
Easy - on the "many" end of the relation - set "Ordered" in the property inspector. Once that is done evolve will add a "_o" field in your db next to the foreign key.
Related
Can anyone explain why service fabric has both IReliableDictionary and IReliableDictionary2 where IReliableDictionary DERIVES from IReliableDictionary2? It makes no sense and the documentation doesn't appear to explain it. Which one are you supposed to use?
https://learn.microsoft.com/en-us/dotnet/api/microsoft.servicefabric.data.collections.ireliabledictionary-2?view=azure-dotnet
Proof:
You are reading the documentation incorrectly. "Derived", means that IReliableDictionary2 is derived from IReliableDictionary. For proof look at ICollection interface in .Net, https://learn.microsoft.com/en-us/dotnet/api/system.collections.icollection?view=netframework-4.7.
You want use IReliableDictionary2 if you need to use Count that doesn't enumerate all items in the dictionary or key enumeration.
IReliableDictionary2 has an additional property Count which is persisted alongside the collection's entries. This allows quick access to the number of entries in the collection, as usually you'd have to enumerate over its entries and calculate the count.
This is not very clear from the API documentation, merely seeing "Oh this has an extra count property" does not, to me, alert that "You should use this if you need to readily access the count". Perhaps you could open an issue here explaining how it's not clear, or edit it and create a PR!
I have a database of million of Objects (simply say lot of objects). Everyday i will present to my users 3 selected objects, and like with tinder they can swipe left to say they don't like or swipe right to say they like it.
I select each objects based on their location (more closest to the user are selected first) and also based on few user settings.
I m under mongoDB.
now the problem, how to implement the database in the way it's can provide fastly everyday a selection of object to show to the end user (and skip all the object he already swipe).
Well, considering you have made your choice of using MongoDB, you will have to maintain multiple collections. One is your main collection, and you will have to maintain user specific collections which hold user data, say the document ids the user has swiped. Then, when you want to fetch data, you might want to do a setDifference aggregation. SetDifference does this:
Takes two sets and returns an array containing the elements that only
exist in the first set; i.e. performs a relative complement of the
second set relative to the first.
Now how performant this is would depend on the size of your sets and the overall scale.
EDIT
I agree with your comment that this is not a scalable solution.
Solution 2:
One solution I could think of is to use a graph based solution, like Neo4j. You could represent all your 1M objects and all your user objects as nodes and have relationships between users and objects that he has swiped. Your query would be to return a list of all objects the user is not connected to.
You cannot shard a graph, which brings up scaling challenges. Graph based solutions require that the entire graph be in memory. So the feasibility of this solution depends on you.
Solution 3:
Use MySQL. Have 2 tables, one being the objects table and the other being (uid-viewed_object) mapping. A join would solve your problem. Joins work well for the longest time, till you hit a scale. So I don't think is a bad starting point.
Solution 4:
Use Bloom filters. Your problem eventually boils down to a set membership problem. Give a set of ids, check if its part of another set. A Bloom filter is a probabilistic data structure which answers set membership. They are super small and super efficient. But ya, its probabilistic though, false negatives will never happen, but false positives can. So thats a trade off. Check out this for how its used : http://blog.vawter.com/2016/03/17/Using-Bloomfilters-to-Avoid-Repetition/
Ill update the answer if I can think of something else.
I'm using titan graph db with tinkerpop plugin. What is the best way to retrieve a vertex using has step?
Assuming employeeId is a unique attribute which has a unique vertex centric index defined.
Is it through label
i.e g.V().has(label,'employee').has('employeeId','emp123')
g.V().has('employee','employeeId','emp123')
(or)
is it better to retrieve a vertex based on Unique properties directly?
i.e g.V().has('employeeId','emp123')
Which one of the two is the quickest and better way?
First you have 2 options to create the index:
mgmt.buildIndex('byEmployeeId', Vertex.class).addKey(employeeId).buildCompositeIndex()
mgmt.buildIndex('byEmployeeId', Vertex.class).addKey(employeeId).indexOnly(employee).buildCompositeIndex()
For option 1 it doesn't really matter which query you're going to use. For option 2 it's mandatory to use g.V().has('employee','employeeId','emp123').
Note that g.V().hasLabel('employee').has('employeeId','emp123') will NOT select all employees first. Titan is smart enough to apply those filter conditions, that can leverage an index, first.
One more thing I want to point out is this: The whole point of indexOnly() is to allow to share properties between different types of vertices. So instead of calling the property employeeId, you could call it uuid and also use it for employers, companies, etc:
mgmt.buildIndex('employeeById', Vertex.class).addKey(uuid).indexOnly(employee).buildCompositeIndex()
mgmt.buildIndex('employerById', Vertex.class).addKey(uuid).indexOnly(employer).buildCompositeIndex()
mgmt.buildIndex('companyById', Vertex.class).addKey(uuid).indexOnly(company).buildCompositeIndex()
Your queries will then always have this pattern: g.V().has('<label>','<prop-key>','<prop-value>'). This is in fact the only way to go in DSE Graph, since we got completely rid of global indexes that span across all types of vertices. At first I really didn't like this decision, but meanwhile I have to agree that this is so much cleaner.
The second option g.V().has('employeeId','emp123') is better as long as the property employeeId has been indexed for better performance.
This is because each step in a gremlin traversal acts a filter. So when you say:
g.V().has(label,'employee').has('employeeId','emp123')
You first go to all the vertices with the label employee and then from the employee vertices you find emp123.
With g.V().has('employeeId','emp123') a composite index allows you to go directly to the correct vertex.
Edit:
As Daniel has pointed out in his answer, Titan is actually smart enough to not visit all employees and leverages the index immediately. So in this case it appears there is little difference between the traversals. I personally favour using direct global indices without labels (i.e. the first traversal) but that is just a preference when using Titan, I like to keep steps and filters to a minimum.
I am trying to design a simple application where in I have two entities Notebook and Note. So Notebook can contain multiple Notes.In RDBMS I could have two tables and have One to Many
relationship between them. I am not sure in MongoDB whether I should not take a two collection
approach or I should embed notes in Notebook collection. What would you suggest?
That seems like a perfectly reasonable situation to use a single collection called Notebook, and each Notebook document contains embedded Notes. You can easily index on embedded documents.
If a Notebook document has a 'notes' key, and value is a list of notes:
{
"notes": [
{"created_on": Date(1343592000000), text: "A note."}
]
}
# create index
db.notebook.ensureIndex({"notes.created_on" : -1})
My opinion is to try and embed as much as possible, and then choose to reference another collection via an id as a second option when the reference needs to be to a more general set of data that is shared and might change. For instance, a collection of category documents which many other collections reference. And the category can be updated over time. But in your case, a note should always belong to a note book
You should ask yourself what kind of queries you will need to run on it. The "by default" approach is to embed them, but there are cases (that will depend on how you plan on using them) where a more relational approach is applicable. So the simple answer is "probably, but you should probably think about it" :)
I currently have an app which lists a number of events (horse riding, party, etc), i want to be able to add these events to a list of 'favourites' which will be stored in core data, but i also want these events to be sorted in the order they were added to favourites. I realise i could just add an index property to the event and sort using a descriptor when i retrieve the events but i would like to be able to add events to multiple lists of favourites, so i don't think that would work.
I've also looked into ordered relationships, which is exactly what i am looking for but requires iOS5, as a last resort i could probably cope with that although i would prefer to be able to find another way to do this if possible. Any ideas?
Thanks.
EDIT: The user can also add and remove lists of favourites so adding a date property and sorting by that would not be possible.
The correct solution is to have a 3rd entity that represents a membership of an event to a favourite list. Let's call it EventInFavourites.
EventInFavourites has two many-to-one relations:
Favourites <-------->> EventInFavourites
This one says that a Favourites can have several Event in it
Event <---------->> EventInFavourites
This one says that an Event can be part of several Favourites lists.
Finally, the position of that event in that favourite list is represented with an attribute of
EventInFavourites, let's say position.
So when you want to add an event to a favorite lists, you create an EventInFavourites instance and you link it to that event and to that favorite list. A bit like this:
EventInFavourites *newFavouriteMembership = [EventInFavourites insertInManagedObjectContext:self.moc];
newFavouriteMembership.event = anEvent;
newFavouriteMembership.favourites = aFavouritesList;
newFavouriteMembership.position = 3; // or whatever
[self.moc save:NULL];
I left out a few details, but that should give you the big picture.
And of course, you can wait for iOS 5.
Go with ordered relationships with iOS 5. iOS devices are updated fairly quickly and I imagine that you would not be forsaking a large percentage of potential customers. Not to mention the time you will save from having to roll your own implementation.
Store the time & date when the item was added to the favorites. Later, when querying the db, order by this timestamp.
With different lists of favorites you might want to store multiple timestamps, one for each list.