I'm building a graphql schema through AWS AppSync and have a question regarding schema structure. My app will show users new posts and have them either join or pass on them. I'm trying to build in a way that I will only show users new posts and not repeat or at least not repeat for a certain amount of time. It's similar to swiping on tinder, they don't show you somebody again if you've already swiped on them. Does anybody have any ideas how to structure this in my schema. Do I need to store references to all of the seen posts in the user model or should I store each swipe as its own model and how should I structure the querying? I'd appreciate any advice on this.
Thanks!
Assuming a post has a creation time, you could keep track of the last (max created time) post they've seen, then display anything after that.
But think about what happens if they've been off the app for 5 minutes, or 5 days, or 5 weeks... depending on the volume of posts you anticipate they could quickly get behind and have to wade through too many older posts.
One thought would be to show the next oldest post, based derived from the creation time of the most recent post they viewed. Unless N number of posts were created since the last time they were online (a threshold you'd have to decide). Then start with displaying the N - Xth post (where X is 5, or 500, again depending on volume) until they're all caught up.
There are lots of ways you could program it, it all depends on your use case, you may want to take "popular" posts into account for example, those might be weighted above/before the other posts in their backlog.
Hope this helped.
Related
Good day, I've struggled with an upcoming forms project architecture, specifications are as such from the stakeholder:
Django framework,
Bootstrap5,
Floating Labels,
Multiple Users that cannot have access to each others db.
Operation Theory:
A law clerk logs in, request a form via API, the questions in the form are somehow saved and presented to a user logging in at different times. After the questions are answered by the user, the Q's and A's are submitted and saved for review before being pushed elsewhere.
Things I'm struggling with:
Should I create two(2) tables and save the questions returned from the API as field entries? Then, once the user is prepared to answer, dynamically present the questions using floating labels and then save the answers to another table?
The questions from the API call are of any length, it can be as little as 5 or as many as 130, how do I create fields at runtime with floating labels accodring to the questionaire length? Also have to match them(Q's and A's) back up for review by a third party.
Let's assume I have a front-end app for a blog and I stored the blog posts in an Elasticsearch instance (this is a hypothetical example).
I want multiple users to be able to mark some blog posts as favorite and the super users to be able to flag blog posts. For marking as favorite, only the user that did the marking is able to see it as marked. For flagging, if one user flags it, all the other users sees it as flagged.
I was thinking about adding a boolean field for the flagging and an array field with the user ids for the marking. This way I can use a boolean query to find flagged posts and for the favorite posts of a user I can use an exists query.
I'm pretty new to Elasticsearch so I'm not sure if this will perform good enough on millions/billions of posts. What other options are there?
Edit: Forgot to mention that I would also like to have paging for the blog posts and be able to filter out/in the flagged or marked posts. For example I want first (ordered by creation date) 10 blog posts that are marked as favorite, or last 10 blog posts flagged.
To make a favorite system one solution is to store the data in a different index with blog_id
user_id
created_at
This way you can easily add remove and search.
I want multiple users to be able to mark some blog posts as favorite
User 1 click on the favorite link of blog 2, system will store in "favorite" index {"user_id":1, "blog_id": 2, "created_at": "2019-10-02 12:00:02", "blog_created_at": "2019-01-01 09:10:11"}
only the user that did the marking is able to see it as marked.
You can search with get by id if you concaten the user_id-blog_id or you can make a search with blog_id, user_id and you can know if the record exist if the blog you display is marked as favorite by the user who read.
Same for list page as you know the user_id and after you build the list of blog_ids you'll display you can make the search and retrieve a list that you will use when you'll display your list of blogs.
This solution will have good performance even for billions of posts.
If you have flag you can also flag your blog post the same way and put a category field.
Depends on how much flag and which kind of flag you'll have you can consider saving in the same index with a category field ['favorite', 'flag', ...] or save in different indices.
Also another thing to check about is using periodic index (monthly, weekly or daily) depend on the number of document you will store and how much update (add/remove favorite) you will have. You can rollup your index in yearly later if you have lass activity on them.
And a last thing, maybe consider using cache to handle frenetic click on favorite button that can lead to add/remove document which will increase the number of deleted document in your index, that can make your index slow.
Edit for the Edit in the question:
For example I want first (ordered by creation date) 10 blog posts
that are marked as favorite, or last 10 blog posts flagged.
You can add the blog creation date in your favorite records "blog_created_at" (I updated the example document). So you can sort by blog creation date and limit your aggregation at 10 if you want the 10 first.
For the other case in your comment:
If I want to get just 10 blog posts, ordered by date, which are not
marked as favorite or not flagged
You can add a field in your blog and set as True if you have a favorite, something like "has_favorite" or "has_flag".
You set as True when you first set as favorite, if it's already favorite you do nothing.
So you can search against this field to filter the blog that don't have favorite.
If somebody remove a favorite you can count how much this blog have favorite if 0 set has_favorite to False. <-- only this case can generate update but it's maybe 0.001% of case so better to focus on the 99% of case. If it increase, need to adapt the solution.
We are a housing association with a large CRM system (2016 & SP1). We have a new requirement that requires our users to be able to search for people who are current (ie not previous) occupants or residents or who are not residents (eg contractors)
For this purpose, we need to search the Person entity which has a related Tenancy entity. Person has TenancyType field with possible (option set) values Occupant, Resident, Contractor. Tenancy has TenancyStatus field with possible (text) values Current and Previous.
We tried using the following filter criteria in the quick view on the Person entity:
thinking that it would return all people who are not previous residents. However we noticed that it would filter out contractors because contractors do not have related tenancy records.
We needed to change the criteria to return all contractors OR all residents and occupants with no previous tenancy. So we changed it to the following:
at which point we got stuck because we noticed that it was not possible to AND together the second and the third conditions as the third one is a related entity.
We are wondering what the best way is to achieve the above bearing in mind that we do not want a separate view for each condition, eg one for residents, one for none residents, etc.
Any help or suggestion is greatly appreciated.
It is not possible to do this with a single query.
Instead, you can use two queries. If you do not want to do that, then using reports (as suggested by Alex) or a BI-solution would be other possibilities.
Thanks to everyone here who spent time answering my question. The following describes the correct answer:
https://community.dynamics.com/crm/f/117/p/241352/666651#666651
I would like to provide users with points when they do a certain thing. For example:
adding article
adding question
answering question
liking article
etc.
Some of them can have conditions like there are only points for first 3 articles a day, but I think I will handle this directly in my code base.
The problem is what would be a good database design to handle this? I think of 3 tables.
user_activities - in this table I will store event types (I use
laravel so it would probably be the event class name) and points for
specific event.
activity_user - pivot table between user_activities and users.
and of course users table
It is very simple so I am worrying that there are some conditions I haven't thought of, and it would come and bite me in the future.
I think you'll need a forth table that is simply "activities" that is simply a list of the kinds of activities to track. This will have an ID column, and then in your user_activities table include an 'activity_id' to link to that. You'll no doubt have unique information for each kind, for example an activities table may have columns like
ID : unique ID per laravel
ACTIVITY_CODE : short code to use as part of application/business logic
ACTIVITY_NAME : longer name that is for display name like "answered a question"
EVENT : what does the user have to do to trigger the activity award
POINT_VALUE: how many points for this event
etc
If you think that points may change in the future (eg. to encourage certain user activities) then you'll want to track the actual point awarded at the time in the user activities table, or some way to track what the points were at any one time.
While I'm suggesting fourth table, what you really need is more carefully worded list of features to be implemented before doing any design work. My example of allowing for points awarded to change over time is such a feature that you don't mention but you'll need to design for if this feature is needed.
Well I have found this https://laracasts.com/lessons/build-an-activity-feed-in-laravel as very good solution. Hope it helps someone :)
Lets say we have a website with posts.
The information we can get is:
post_time (from site launch)(doesn't change)
post_rating (changes over time)
number_of_comments (changes over time)
what would be a good formula in order for the website to keep fresh and good posts at the top without seeing the same post at the top again.
I figured I should give "weights" to each of the fields above, where
post_time will have the heaviest weight.
What kind of sorting does 9gag use for instance?
the difference between post_time can vary between 1 second and minutes/hours
edit:
Clarification:
I have a database where I keep all of this information, what I need
is a formula that will keep the posts page up to date and a user that logs now and in 20 minutes will see different posts.
Ok so the simplest way I found is as follows:
Add an additional DATE field to the Posts SQL table that is called top_date
Select from the posts table all highest ratings that has top_date NULL
update top_date of a wanted post with current time stamp
now the posts page will use DESC by top_date.
also there can be a function that will be called every few minutes that will
gather the top rating (RATING ONLY) posts without top_date and randomly choose
one to be updated.
If i was unclear feel free to ask any question here or in private message.