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.
Related
There are three groups of markers (grocery stores, clothing stores, pharmacies). Each of them is from a different company. I need to make a display on the map by stores and their companies. When switching to stores, so that only the selected companies are displayed. That is, when selecting a store, other stores should not be displayed. Input radio -> (grocery stores, clothing stores, pharmacies), input checkbox -> (company1, company2,...). How can I make it so that when selecting, for example, "clothing stores", only the clothing store companies with an optional selection by company are shown?
Here's an example: https://codesandbox.io/s/billowing-cache-805g6?file=/index.html
This example uses buttons but you could easily switch them to radio buttons if you would rather use those.
The code is quite simple. One page load, it creates the map. I defined a static array of objects that are companies and each company contains objects by store types (yours might be different).
The doLoadCompany function takes a the id of the company and if it matches, it will loop through the grocery store object for that company and load the markers onto the map. Before it loads the new grocery stores though, it will clear the previously loaded company, if one existed.
This is one simple example. It can get much more complicated depending on your object or it could be simpler again, depending on your object. The basics is to determine a way to identify the company you are wanting to load data for and then load that data. If you're doing this from an API, I would return only the data that you need for the specific company then loop through the data set and plot the markers based on their coordinates.
I'm writing a Flutter web/mobile calendar application / todo list, the main feature of which is a long list of items (appointments, tasks, and the like).
Much of the time, the list won't be longer than a few hundred items. But it should be able to scale to thousands of items, as many as the user wants. Not too hard to do should the user make many repeating items. I'm using ReorderableListView.builder to virtualize the list. The part I'm struggling with is when to load the list data and how to store it.
Important: When the user picks a day, the list can jump to somewhere in the middle... and can scroll back to the top of the list.
The easiest thing to do would be to just load all data up to the users position. But this means storing a potentially very large list in memory at best, and in the web application it means requesting way more data than is really needed.
A good summary of the problem might be: Jumping to particular day is more challenging than jumping to a known index on the list. It's not easy to know what an item's index would be in a fully constructed version of the list without fully constructing the list up to that item. Yes, you can get items at particular date, but what if you wanted to get fifty items before a particular date, and fifty items after a particular date (useful for keeping scrolling smooth)? There could be a huge gap, or there could be a whole ton of items all clustered on one day.
A complication is that not all items in the list are items in the database, for example day headers. The day headers need to behave like regular items and not be attached to other items when it comes to the reordering drag animation, yet storing them as records in the database feels wrong. Here's an image of the web application to give you some idea:
THIS ANSWER IS MY OWN WORK IN PROGRESS. OPEN TO BETTER ANSWERS, CORRECTIONS.
I like the answer here (Flutter: Display content from paginated API with dynamic ListView) and would like to do something like it.
I would do this both for web app, where there's http bottlenecks. I would also do this for the mobile app, even when all data is in the database. Why keep the entire list in memory when you don't have to? (I have very little mobile development experience, so please correct me if I'm wrong)
Problem:
Jumping to particular day is more challenging than jumping to known index on the list. It's not easy to know what an item's index would be in a fully constructed version of the list without fully constructing the list up to that item.
Solution I'm leaning toward:
ReferencesList + keyValueStorage solution
Store the item ids in order as well as key value pairs of all items by id as a json list in NoSql. This list will include references to items, with day headings included and represented by something like 'dh-2021-05-21' or its epoch time. This list will be very lightweight, just a string per item, so you don't need to worry about holding it all in memory. Item data can be pulled out of storage whenever it's built. (Should this be a problem in Sembast or hive? Hive, and here's why: https://bendelonlee.medium.com/hive-or-sembast-for-nosql-storage-in-flutter-web-fe3711146a0 )
When a date is jumped to, run a binary search on this list to find its exact position and scroll to that position. You can easily preload, say 30 items before and 50 items after that position.
other solutions:
SplayTreeMap + QuerySQLByDate Solution:
When jumping, since you don't know the index, insert it into a new SplayTreeMap at an arbitrarily high index, say 100 * number_of_list_items_in_database just to be safe. Run two queries, on ascending from scrolled to date, and one descending from it. Cache these queries and return them in paged form. Should the user reach the beginning of the list, simply prevent them from scrolling further up the list manually with a ScrollController or something like it.
I'm having some issues to correctly design the domain that I'm working on.
My straightforward use case is the following:
The user (~5000 users) can access to a list of ads (~5 millions)
He can choose to add/remove some of them as favorites.
He can decide to show/hide some of them.
I have a command which will mutate the aggregate state, to set Favorite to TRUE, let's say.
In terms of DDD, how should I design the aggregates?
How design the relationship between a user and his favorite's ads selection?
Considering the large numbers of ads, I cannot duplicate each ad inside a user aggregate root.
Can I design a Ads aggregateRoot containing a user "collection".
And finally, how to handle/perform the readmodels part?
Thanks in advance
Cheers
Two concepts may help you understand how to model this:
1. Aggregates are Transaction Boundaries.
An aggregate is a cluster of associated objects that are considered as a single unit. All parts of the aggregate are loaded and persisted together.
If you have an aggregate that encloses a 1000 entities, then you have to load all of them into memory. So it follows that you should preferably have small aggregates whenever possible.
2. Aggregates are Distinct Concepts.
An Aggregate represents a distinct concept in the domain. Behavior associated with more than one Aggregate (like Favoriting, in your case) is usually an aggregate by itself with its own set of attributes, domain objects, and behavior.
From your example, User is a clear aggregate.
An Ad has a distinct concept associated with it in the domain, so it is an aggregate too. There may be other entities that will be embedded within the Ad like valid_until, description, is_active, etc.
The concept of a favoriting an Ad links the User and the Ad aggregates. Your question seems to be centered around where this linkage should be preserved. Should it be in the User aggregate (a list of Ads), or should an Ad have a collection of User objects embedded within it?
While both are possibilities, IMHO, I think FavoriteAd is yet another aggregate, which holds references to both the User aggregate and the Ad aggregate. This way, you don't burden the concepts of User or the Ad with favoriting behavior.
Those aggregates will also not be required to load this additional data every time they are loaded into memory. For example, if you are loading an Ad object to edit its contents, you don't want the favorites collection to be loaded into memory by default.
These aggregate structures don't matter as far as read models are concerned. Aggregates only deal with the write side of the domain. You are free to rewire the data any way you want, in multiple forms, on the read side. You can have a subscriber just to listen to the Favorited event (raised after processing the Favorite command) and build a composite data structure containing data from both the User and the Ad aggregates.
I really like the answer given by Subhash Bhushan and I want to add another approach for you to consider.
If you look closely at your question you will see that you've made the assumption that an aggregate can 'see' everything that the user does when they are interacting with the UI. This doesn't need to be so.
Depending on the requirements of the domain you don't need to hold a list of any Ads in the aggregate to favourite them. Here's what I mean:
For this example, it doesn't matter where the the 'favourite' ad command sits. It could be on the user aggregate or a specific aggregate for handling the concept of Favouriting. The command just needs to hold the id of the User and the Ad they are favouriting.
You may need to handle what happens if a user or ad is deleted but that would just be a case of an event process manager listening to the appropriate events and issuing compensating commands.
This way you don't need to load up 5 million ads. That's a job for the read model and UI, not the domain.
Just a thought.
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 have a Core Data model that looks like this…
Event <<-------->> Date
The idea being that an Event can have many Dates and a Date can have many Events. I need my tableview to list Events with SectionHeaders displaying the Dates.
My issue is that I don't know how to set this up so that an Event can reoccur each time a new date is displayed in the SectionHeader.
When I setup my Predicate to collect all the Dates for each Event it does not allow for a duplication of the event when setting the sectionNameKeyPath on the FRC.
Instead of a many to many relationship, wouldn't it make sense to just have a date property of your event object, and just look up all events for a particular date? I'd imagine this is possible using NSPredicate.
The minor downside is you'd have to have an entry for each reoccurring event and modify all of them when one is changed. On the upside this is functionally beneficial as it allows users to modify individual events in series, or cancel / delete an event without effecting the rest in the series.
Jim,
The NSFetchedResultsController is restricted to just a single entity. Hence, many complex queries are not possible or require complex queries using sub-queries. In my experience, unless your data model fits into this narrow design, then you'll have trouble. I retreat to listening for the context did save notification and processing the objects that change or are inserted directly.
Andrew