StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POFinding unique products (never seen before by a user) in a datastore sorted by a dynamically changing value (i.e. product rating)
text
Body
copied!<p>been trying to solve this problem for a week and couldn't come up with any solutions in all my research so I thought I'd ask you all.</p> <p>I have a "Product" table and a "productSent" table, here's a quick scheme to help explain:</p> <pre><code>class Product(ndb.Model): name = ndb.StringProperty(); rating = ndb.IntegerProperty class productSent(ndb.Model): <--- the key name here is md5(Product Key+UUID) pId = ndb.KeyProperty(kind=Product) uuId = ndb.KeyProperty(kind=userData) action = ndb.StringProperty() date = ndb.DateTimeProperty(auto_now_add=True) </code></pre> <p>My goal is to show users the highest rated product that they've never seen before--fast. So to keep track of the products users have seen, I use the productSent table. I created this table instead of using Cursors because every time the rating order changes, there's a possibility that the cursor skips the new higher ranking product. An example: assume the user has seen products 1-24 in the db. Next, 5 users liked product #25, making it the #10 product in the database--I'm worried that the product will never be shown again to the user (and possibly mess things up on a higher scale).</p> <p>The problem with the way I'm doing it right now is that, once the user has blown past the first 1,000 products, it really starts slowing down the query performance. Because I'm literally pulling 1,000+ results, checking if they've been sent by querying against the productSent table (doing a keyName lookup to speed things up) and going through the loop until 15 new ones have been detected.</p> <p>One solution I thought of was to add a repeated property (listProperty) to the Product table of all the users who have seen a product. Or if I don't want to have inequality filters I could put a repeated property of all the users who haven't seen a product. That way when I query I can dynamically take those out. But I'm afraid of what happens when I have 1,000+ users:</p> <p>a) I'll go through the roof on the limit of repeated properties in one entity. b) The index size will increase size costs</p> <p>Has anyone dealt with this problem before (I'm sure someone has!) Any tips on the best way to structure it?</p> <p><strong>update</strong> Okay, so had another idea. In order to minimize the changes that take place when a rating (number of likes) changes, I could have a secondary column that only has 3 possible values: positive, neutral, negative. And sort by that? Ofcourse for items that have a rating of 0 and get a 'like' (making them a positive) would still have a chance of being out of order or skipped by the cursor--but it'd be less likely. What do y'all think?</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload