like count sometimes shows negative values

[jywarren]

http://publiclab.org/wiki/near-infrared-camera shows -4

some pages briefly show -1 until they load the ajax -- however that could be a separate issue which we could solve by including the like button partial directly instead of ajaxing it on the first page load

[btbonval]

SELECT * FROM node WHERE cached_likes < 0;

yields -1 on Big Sur, barnstars, norcal, jerusalem, DIYBIO, infragram media, i-farm 2013, sharing-images; -8 on NIR cams, -3 on philly, -2 on infragram, -7 on NIR imaging.

Pretty display (includes node title) of each problem node with its actual like count:

SELECT node_selections.nid, sum(liking), cached_likes, title FROM
node_selections, node WHERE node.nid = node_selections.nid AND cached_likes
< 0 GROUP BY node_selections.nid;

This indicates all the negative counts should have a like count of 1, except for NIR cams and infragram at 2 and philly at 3.

A modification of the above query should be used to reset the cached_likes to their actual counts for /all/ nodes. Unfortunately mass updates don't work well in SQL, so a loop would iterate over values 0 to max(sum(liking)). It might look something like this:

for i in range 0...max(sum(liking)):
   UPDATE node SET cached_likes = i WHERE nid IN (SELECT nid FROM
node_selections WHERE sum(liking) == i GROUP BY nid)

... now why is this happening?

[btbonval]

This will make things easier:

CREATE VIEW view_node_like_count AS SELECT node_selections.nid, sum(liking)
AS num_likes, cached_likes, title FROM node_selections, node WHERE node.nid
= node_selections.nid GROUP BY node_selections.nid;

check what doesn't match:

SELECT * FROM view_node_like_count WHERE cached_likes <> num_likes;

fix them:

UPDATE node,view_node_like_count
SET node.cached_likes = view_node_like_count.num_likes
WHERE
node.nid = view_node_like_count.nid AND
node.cached_likes <> view_node_like_count.num_likes;

This has been done. cached_likes are synchronized for the moment.

The view should be checked occasionally for out-of-sync (see "check what doesn't match" above), assuming the like code doesn't get revamped. Hint: the like code should be revamped as in ticket #135

On Sun, May 26, 2013 at 9:01 PM, Bryan btbonval@gmail.com wrote:

SELECT node WHERE cached_likes < 0;

yields -1 on Big Sur, barnstars, norcal, jerusalem, DIYBIO, infragram media, i-farm 2013, sharing-images; -8 on NIR cams, -3 on philly, -2 on infragram, -7 on NIR imaging.

Pretty display (includes node title) of each problem node with its actual like count:

SELECT node_selections.nid, sum(liking), cached_likes, title FROM
node_selections, node WHERE node.nid = node_selections.nid AND cached_likes
< 0 GROUP BY node_selections.nid;

This indicates all the negative counts should have a like count of 1, except for NIR cams and infragram at 2 and philly at 3.

A modification of the above query should be used to reset the cached_likes to their actual counts for /all/ nodes. Unfortunately mass updates don't work well in SQL, so a loop would iterate over values 0 to max(sum(liking)). It might look something like this:

for i in range 0...max(sum(liking)):
   UPDATE node SET cached_likes = i WHERE nid IN (SELECT nid FROM
node_selections WHERE sum(liking) == i GROUP BY nid)

... now why is this happening?

On Fri, May 17, 2013 at 12:37 PM, Jeffrey Warren <notifications@github.com

wrote:

http://publiclab.org/wiki/near-infrared-camera shows -4

some pages briefly show -1 until they load the ajax -- however that could be a separate issue which we could solve by including the like button partial directly instead of ajaxing it on the first page load

— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/issues/129 .

[btbonval]

SELECT node WHERE cached_likes < 0;

yields -1 on Big Sur, barnstars, norcal, jerusalem, DIYBIO, infragram media, i-farm 2013, sharing-images; -8 on NIR cams, -3 on philly, -2 on infragram, -7 on NIR imaging.

Pretty display (includes node title) of each problem node with its actual like count:

SELECT node_selections.nid, sum(liking), cached_likes, title FROM
node_selections, node WHERE node.nid = node_selections.nid AND cached_likes
< 0 GROUP BY node_selections.nid;

This indicates all the negative counts should have a like count of 1, except for NIR cams and infragram at 2 and philly at 3.

A modification of the above query should be used to reset the cached_likes to their actual counts for /all/ nodes. Unfortunately mass updates don't work well in SQL, so a loop would iterate over values 0 to max(sum(liking)). It might look something like this:

for i in range 0...max(sum(liking)):
   UPDATE node SET cached_likes = i WHERE nid IN (SELECT nid FROM
node_selections WHERE sum(liking) == i GROUP BY nid)

... now why is this happening?

[btbonval]

This will make things easier:

CREATE VIEW view_node_like_count AS SELECT node_selections.nid, sum(liking)
AS num_likes, cached_likes, title FROM node_selections, node WHERE node.nid
= node_selections.nid GROUP BY node_selections.nid;

check what doesn't match:

SELECT * FROM view_node_like_count WHERE cached_likes <> num_likes;

fix them:

UPDATE node,view_node_like_count
SET node.cached_likes = view_node_like_count.num_likes
WHERE
node.nid = view_node_like_count.nid AND
node.cached_likes <> view_node_like_count.num_likes;

This has been done. cached_likes are synchronized for the moment.

The view should be checked occasionally for out-of-sync (see "check what doesn't match" above), assuming the like code doesn't get revamped. Hint: the like code should be revamped as in ticket #135

[jywarren]

cool, wait, done as in you ran the SQL on the production box?

[btbonval]

yes, if plots2 is running publiclab.org, then I synchronized the values there. they certainly needed it. On May 27, 2013 8:35 AM, "Jeffrey Warren" notifications@github.com wrote:

cool, wait, done as in you ran the SQL on the production box?

— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/issues/129#issuecomment-18496501 .

[jywarren]

super

On Mon, May 27, 2013 at 12:59 PM, Bryan Bonvallet notifications@github.comwrote:

yes, if plots2 is running publiclab.org, then I synchronized the values there. they certainly needed it. On May 27, 2013 8:35 AM, "Jeffrey Warren" notifications@github.com wrote:

cool, wait, done as in you ran the SQL on the production box?

— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/issues/129#issuecomment-18496501> .

— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/issues/129#issuecomment-18507235 .

[jywarren]

Perhaps this just needs a synchronization again, but I'm seeing "(2)" on some notes that have no likes, or 3 on this one that actually has only one: http://publiclab.org/notes/patcoyle/5-27-2012/flew-iphonechdk-robust-prototype-2-cameras-triggering

We could set up a cron script to flush the count but that seems a bit cludgy...

[btbonval]

88 pages have gone out of sync since the last synchronization done back a month ago.

I'd love to know how these things are getting out of sync. Looking at the code hasn't helped, but the refactoring of #135 might fix it? Without knowing why this happens, it'd be hard to tell. The server side code should only add or remove a like from a user if it is possible to do so, and caching is updated at the same time. It's a little concerning.

Perhaps caching page likes causes more problems than it solves, and it'd be better to run a count() rather than creating a cron job to clean these up every so often.

Here are the mismatched likes:

mysql> SELECT * FROM view_node_like_count WHERE cached_likes <> num_likes;
+------+-----------+--------------+----------------------------------------------------------------------------------------------------+
| nid  | num_likes | cached_likes | title                                                                                              |
+------+-----------+--------------+----------------------------------------------------------------------------------------------------+
|   37 |         0 |            2 | Lima                                                                                               |
|   43 |         0 |            2 | Example NDVI usage in a vineyard                                                                   |
|   82 |         0 |            2 | Mapping Curriculum Image Processing                                                                |
|   87 |         0 |            2 | Community Blog                                                                                     |
|  102 |         0 |            2 | Quantify wetland from aerial UV photo                                                              |
|  194 |         1 |           -1 | Chandeleur Islands, Louisiana                                                                      |
|  210 |         0 |            2 | Bonnet Carre Spillway                                                                              |
|  219 |         0 |            2 | Testing new false color gradients for NDVI                                                         |
|  255 |         0 |            2 | Chandeleur Islands (East), Louisiana                                                               |
|  266 |         0 |            2 | Chandeleur Islands, Louisiana                                                                      |
|  292 |         0 |            2 | Wherecamp, Stanford, Palo Alto, California                                                         |
|  298 |         0 |            2 | calculating pixel resolution                                                                       |
|  328 |         2 |            0 | Presentations                                                                                      |
|  369 |         0 |            2 | Yet another soda bottle camera house                                                               |
|  375 |         0 |            2 |  Capitol Street, Vallejo, California                                                               |
|  390 |         0 |            2 | mapping curriculum: first flight                                                                   |
|  397 |         0 |            2 | mapping curriculum publishing                                                                      |
|  398 |         0 |            2 | Mapping Curriculum: Research Applications                                                          |
|  400 |         0 |            2 | Mapping Curriculum: Activities                                                                     |
|  402 |         0 |            2 | Mapping Curriculum: GIS Applications                                                               |
|  420 |         0 |            2 | Mapping Curriculum: Map Production with PLOTS Map Toolkit                                          |
|  442 |         0 |            2 | Pacific Northwest College of Art Workshop                                                          |
|  443 |         0 |            2 | East Burnside & 65th - Portland, Oregon                                                            |
|  447 |         0 |            2 | PLOTS Map Toolkit                                                                                  |
|  481 |         0 |            2 | Mexico City, Mexico                                                                                |
|  502 |         0 |            2 | MapKnitter 1.0 released today, turn aerial photos into GeoTiffs!                                   |
|  568 |         0 |            2 | Hydrogen Sulfide Sensing                                                                           |
|  687 |         0 |            2 | spectrum matching                                                                                  |
|  699 |         0 |            2 | thermal photography review                                                                         |
|  732 |         0 |            2 | Efficient Image Sorting with Finder & Preview (Mac)                                                |
|  735 |         0 |            2 | Idea for single camera ndvi/nrg infrared analysis                                                  |
|  785 |         0 |            2 | Balloon Mapping kit orders                                                                         |
|  813 |         0 |            2 | Balloon Mapping Kit (retail)                                                                       |
|  832 |         0 |            2 | T-bracket Dual Camera Rig                                                                          |
| 1541 |         0 |            2 | Grassroots NDVI - time series                                                                      |
| 1635 |         0 |            2 | iPhone intervalometer app geotags photos                                                           |
| 1667 |         0 |            2 | Air Column Monitor                                                                                 |
| 1697 |         0 |            2 | Server status                                                                                      |
| 1732 |         0 |            2 | Hydrogen Balloons                                                                                  |
| 1789 |         1 |           -1 | Mailing lists                                                                                      |
| 1796 |         0 |            2 | Dual camera kit electronics                                                                        |
| 1854 |         0 |            2 | Juice jug rig                                                                                      |
| 1894 |         0 |            2 | Endurance of visible/NIR camera and timer                                                          |
| 1935 |         0 |            2 | Mildmay community, London UK                                                                       |
| 1946 |         0 |            2 | Flight-ready MK111 timer                                                                           |
| 1953 |         0 |            2 | Grassroots Mapping Forum: Notes on process and automation  pt.1                                    |
| 1955 |         0 |            2 | Grassroots Mapping Forum: Notes on process and automation pt.2: new templates                      |
| 2138 |         0 |            2 | Lee, NH � Help and learn about documenting cover crops using balloon mapping and spectral analysis |
| 2220 |         1 |            3 | Flew iPhone/CHDK robust prototype, 2 cameras triggering                                            |
| 2491 |         0 |            2 | Ecosynth: upcoming open source 3d mapping for forests                                              |
| 2557 |         0 |            2 | Trash Can Rig in Action                                                                            |
| 2719 |         0 |            2 | Photo monitoring plugin for ImageJ/Fiji                                                            |
| 2740 |         0 |            2 | Kite mapping tundra plots                                                                          |
| 2918 |         0 |            2 | Shenandoah Valley                                                                                  |
| 2930 |         0 |            2 | Yellow Bar Island - Dredge Reuse and FAA permitting                                                |
| 3014 |         0 |            2 | Carabiner Kite Line Attachment                                                                     |
| 3095 |         0 |            2 | Instructions for creating local mailing lists                                                      |
| 3562 |         0 |            2 | Testing coffee spectra at Toscanini's                                                              |
| 3715 |         0 |            2 | Staff call notes 8 20 2012                                                                         |
| 3827 |         0 |            2 | Skane, Sweden                                                                                      |
| 3908 |         0 |            2 | Raspberry Pi-in-the-sky                                                                            |
| 4072 |         0 |            2 | Machine Project. Los Angeles, California.                                                          |
| 4528 |         0 |            2 | Echo Park Neighborhood. Los Angeles, California.                                                   |
| 4529 |         0 |            2 | Art Center. Pasadena, California.                                                                  |
| 4860 |         1 |            3 | Mapping neighborhoods in Kampala, Uganda                                                           |
| 4952 |         0 |            2 | Wobble adjustments for simple juice bottle rig                                                     |
| 4965 |         0 |            2 | Newsletter                                                                                         |
| 5220 |         0 |            2 | Mapping Sewage Flows in the Gowanus Canal after Sandy flood damages                                |
| 5497 |         0 |            2 | Conflans. Agonges, France.                                                                         |
| 5535 |         0 |            2 | Appoquinimink Wildlife Area. Blackbird Creek, Delaware.                                            |
| 5741 |         1 |            3 | Attempt at Distance Spectrometery                                                                  |
| 5901 |         0 |            2 | gowanus canal                                                                                      |
| 5981 |         0 |            2 | Air Quality Egg in CHCS Classroom                                                                  |
| 6060 |         0 |            2 | Opening up a Spectronic 20                                                                         |
| 6106 |         0 |            2 | Mobile Spectrometer Design Update                                                                  |
| 6108 |         0 |            2 | prototype juice bottle bottom dual camera rig                                                      |
| 6130 |         0 |            2 | Passenger Pigeon methods:  getting your location                                                   |
| 6223 |         0 |            2 | Plastics options for spectrometers                                                                 |
| 6281 |         0 |            2 | Opera and Google Chrome                                                                            |
| 6429 |         0 |            2 | Ideas for Air Quality Egg 2.0                                                                      |
| 6437 |         0 |            2 | Re-presenting preliminary Air Quality Egg data                                                     |
| 6580 |         0 |            2 | The comparison of DVD and CD using halogen, incandescent, and fluorescent lamps                    |
| 7315 |         2 |            0 | Jerusalem                                                                                          |
| 7408 |         2 |            0 | DIYBIO Ideas and Applications                                                                      |
| 7751 |         0 |            2 | Kite Club Pontchartrain                                                                            |
| 7902 |         0 |            2 | Fort Mason Community Garden NRG. San Francisco, California                                         |
| 7903 |         0 |            2 | Fort Mason Community Garden NDVI Greyscale. San Francisco, California.                             |
| 7904 |         0 |            2 | Fort Mason Community Garden NDVI False Color. San Francisco, California.                           |
+------+-----------+--------------+----------------------------------------------------------------------------------------------------+
88 rows in set (0.04 sec)

[btbonval]

I just ran the synchronization thingy (noted above) to fix the async above.

[btbonval]

According to this, likes only get modified if they are being changed in the Like table. The change to cached_likes occurs in the same transaction as the change to the Like table.

This code would not be affected by any modifications to the JS planned in #135

    # Check if the value changed.
    if like.liking_changed?
      node = DrupalNode.find(params[:id])
      if like.liking && node.type == "note"
        SubscriptionMailer.notify_note_liked(node,like.user)
        node.cached_likes = node.cached_likes + 1
      else
        node.cached_likes = node.cached_likes - 1
      end

      # Save the changes.
      ActiveRecord::Base.transaction do
        node.save!
        like.save!
      end

[btbonval]

if like.liking && node.type == "note" ... else is a problem.

If node.type != "note", values will be decremented under the else clause.

Might be better as

      if like.liking 
        if node.type == "note"
            SubscriptionMailer.notify_note_liked(node,like.user)
        end
        node.cached_likes = node.cached_likes + 1
      else 
        node

[btbonval]

above code got snipped, but the main fix is there. above fix commit to 8c114ebfbf7f76ad26b33a521720a67639a75a85

This problem is probably not gone.

[jywarren]

huh, sorry i missed out on all this as I fell ill for a couple days at the end of last week. Do you think there's some other latent bug, or you just haven't seen if this works yet?

[btbonval]

I think the patch I submitted was a fix for something you added later for email notification. I think the synchronization issue showed up prior to the notification modification.

If that fix was the only thing needed, then only non-notes would get out of sync. I just popped into the database and I see four nodes out of sync: 1 page, 2 maps, 1 tool, and 1 note. Because there exists at least one note which is out of sync, the underlying problem was not due to type checking for notes. I was speculating, but now I'm certain that the above fix was only good manners and did not solve the problem at hand.

I thought of something in the shower today: the changes to node.cached_likes and like.liking occur within an atomic transaction, however the check for like.liking occurs outside that atomicity. With just the right timing, like.liking could change between the if check and the transaction that commits modifications.

I bet if the whole shebang were put into one atomic transaction, we should be guaranteed that cached_likes only changes when like.liking has had a valid change. I'm not entirely sure how to manage that in Ruby. It should be just a matter of moving the transaction.do block up.

[btbonval]

1+2+1+1 = 4? I could claim typo but it is because I'm a mathematician. Everyone knows mathematicians can't do arithmetic.

[btbonval]

Commit 493ad9d should hopefully fix the problem; if not, I must be misunderstanding something fundamental about how Ruby talks to the database.

I built the like check into the same atomic transaction as the cache update and like update, so they all happen together or they all do not happen together, without possibility of another call coming somewhere between. Mutual exclusivity should nix the issue.

The cached counts will need to be synced after this new master is published to the world, and then we play the waiting game.

[jywarren]

super... btw we are synced again on the openid changes in git, so you can go ahead and deploy if you like. Whee!!

On Thu, Jul 4, 2013 at 10:46 PM, Bryan Bonvallet notifications@github.comwrote:

Commit 43ad9d should hopefully fix the problem; if not, I must be misunderstanding something fundamental about how Ruby talks to the database.

I built the like check into the same atomic transaction as the cache update and like update, so they all happen together or they all do not happen together, without possibility of another call coming somewhere between. Mutual exclusivity should nix the issue.

The cached counts will need to be synced after this new master is published to the world, and then we play the waiting game.

— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/issues/129#issuecomment-20499289 .

[btbonval]

Production has been updated with newest commit and the service ./restarted. The like caches have been synchronized in the production database.

Check on this in 3-4 weeks. If the like caches are still out of sync, rage quit life.

[jywarren]

maybe we should rage quit life? I don't know if this had drifted, or what, but it was at 2 stars when i got to the page, so I think it's unrelated to my having "liked" it, which I did after I saw the 2 like count:

http://publiclab.org/notes/eustatic/7-23-2012/uv-detection-oil-corexit-gulf-beaches

Could be an unrelated problem, i guess.

[btbonval]

Yeah, UV detection drifted.

| nid  | num_likes | cached_likes | title  
...
| 1724 |         1 |            3 | 370nm UV detection of Corexit-dispersed oil on Gulf Coast Beaches
...
57 rows in set (0.04 sec)

along with 56 other nodes that got out of sync. I wonder if there is something else modifying cached_likes outside of the code that was modified above? After a quick look, the only place in code that explicitly modifies cached_likes is in a transaction which should keep things pretty well synced.

I'm going to see if there are any trends. Right now, cached_likes is consistently over reporting values. That means cached_likes is being incremented without an addition to node_selections, or cached_likes is not being decremented with node_selections.

[btbonval]

I did notice some interesting things that I can't easily explain. nodes with id 308, 344, 370, 461, 468, 489, 521, and many more, have only 1 single row entered into node_selections, with a liking and following of 0. The weird thing is that on all those nodes, cached_likes = 2.

One row in node_selections indicates that 1 person had liked the node or followed the node, then chose to stop liking or stop following the node. AFAIK, rows are never deleted, so if there is only 1 row, regardless of the values, only 1 person set values for that node. The fact that cached_likes shows 2 is an afront to logic and sensibility!

[btbonval]

Might be good to put a debug check in to see if the changed? function works as expected. It might be that like is being set to 1, then set to 0, but incremented each time in cached_like for count of 2. This seems very unlikely, but a little if-check with puts might help determine if the changed? function works reliably.

[ebarry]

Please don't rage quit life -- you guys are doing awesome!!! On Jul 16, 2013 8:55 PM, "Bryan Bonvallet" notifications@github.com wrote:

Might be good to put a debug check in to see if the changed? function works as expected. It might be that like is being set to 1, then set to 0, but incremented each time in cached_like for count of 2. This seems very unlikely, but a little if-check with puts might help determine if the changed? function works reliably.

— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/issues/129#issuecomment-21085244 .

[btbonval]

174 referenced above should fix this issue.

synchronized, hopefully for the last time:

mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)

mysql> UPDATE node,view_node_like_count SET node.cached_likes = view_node_like_count.num_likes WHERE node.nid = view_node_like_count.nid AND node.cached_likes <> view_node_like_count.num_likes;
Query OK, 370 rows affected (0.11 sec)
Rows matched: 370  Changed: 370  Warnings: 0

mysql> COMMIT;
Query OK, 0 rows affected (0.22 sec)

Leave this ticket open for a month, check on the synchronization status.

[btbonval]

mysql> SELECT * FROM node WHERE cached_likes < 0;
Empty set (0.01 sec)

yaaay

mysql> SELECT count(*) FROM view_node_like_count WHERE cached_likes <> num_likes;
+----------+
| count(*) |
+----------+
|      121 |
+----------+
1 row in set (0.07 sec)

booooo

[btbonval]

Since there is one person set for this particular table, it appears as though the person liked or followed the page (to get the row entered) and then unliked or unfollowed the page (to have both columns set to 0). Cached likes shows 2.

Here are two possibilities:

1. Other users were involved, got deleted, and the user deletion did not update the cached likes
2. Unliking the page added to cached_likes instead of subtracting

Neither of the above seem plausible, since users are never deleted and the logic for unliking is pretty clear.

mysql> SELECT * FROM view_node_like_count WHERE nid=33;
+------+-----------+--------------+--------------------+
| nid  | num_likes | cached_likes | title              |
+------+-----------+--------------+--------------------+
|   33 |         0 |            2 | The Roomba Project |
+------+-----------+--------------+--------------------+
1 row in set (0.07 sec)

mysql> SELECT * FROM node_selections WHERE nid = 33;
+---------+------+-----------+--------+
| user_id | nid  | following | liking |
+---------+------+-----------+--------+
|  313307 |   33 |         0 |      0 |
+---------+------+-----------+--------+
1 row in set (0.02 sec)

[btbonval]

Crazy coincidence.

I picked out two more pages which had mismatched cached likes, and they also had the user 313307 with 0 following and 0 liking. Why does this user keep showing up?

mysql> SELECT user_id, count(*) AS count FROM view_node_like_count, node_selections WHERE cached_likes <> num_likes AND node_selections.nid = view_node_like_count.nid GROUP BY user_id ORDER BY count DESC LIMIT 5;
+---------+-------+
| user_id | count |
+---------+-------+
|  313307 |    54 |
|   53894 |    10 |
|       1 |     9 |
|     554 |     9 |
|       7 |     5 |
+---------+-------+
5 rows in set (0.21 sec)

Something is very crazy about that user. The other four users are fairly well known folks, so it's probably just coincidence.

[btbonval]

Sounds like it is time to check the synchronization of likes again. I thought the relational database fixes would have covered this problem (it certainly doesn't appear as often), but we still sometimes see -1 likes.

My current guess is that the server hasn't updated the client promptly, and that a refresh will clear up the problem. But it is still visible enough for a user to report. It might be time to clean up the hack that causes the -1 in the first place.

[ebarry]

yeah i still see -1s every once in a while

@lizbarry http://twitter.com/lizbarry

On Tue, Jun 10, 2014 at 2:42 PM, Bryan Bonvallet notifications@github.com wrote:

Sounds like it is time to check the synchronization of likes again. I thought the relational database fixes would have covered this problem (it certainly doesn't appear as often), but we still sometimes see -1 likes.

My current guess is that the server hasn't updated the client promptly, and that a refresh will clear up the problem. But it is still visible enough for a user to report. It might be time to clean up the hack that causes the -1 in the first place.

— Reply to this email directly or view it on GitHub https://github.com/jywarren/plots2/issues/129#issuecomment-45654398.

[btbonval]

When you see them, can you refresh the page and wait a moment? Just to help me test the theory.

I plan to go dig in the database and see what sort of tom foolery is going on back there to cover all the bases.

On Tue, Jun 10, 2014 at 12:23 PM, Liz Barry notifications@github.com wrote:

yeah i still see -1s every once in a while

@lizbarry http://twitter.com/lizbarry

On Tue, Jun 10, 2014 at 2:42 PM, Bryan Bonvallet notifications@github.com

wrote:

Sounds like it is time to check the synchronization of likes again. I thought the relational database fixes would have covered this problem (it certainly doesn't appear as often), but we still sometimes see -1 likes.

My current guess is that the server hasn't updated the client promptly, and that a refresh will clear up the problem. But it is still visible enough for a user to report. It might be time to clean up the hack that causes the -1 in the first place.

— Reply to this email directly or view it on GitHub https://github.com/jywarren/plots2/issues/129#issuecomment-45654398.

— Reply to this email directly or view it on GitHub https://github.com/jywarren/plots2/issues/129#issuecomment-45659579.

[btbonval]

281 like counts are out of sync. In all cases, cached likes is larger than the actual likes parsed out of the appropriate tables and summed up.

Seems like cached_likes is not updated when likes are removed through some particular means, perhaps when a user is deleted or banned or something? Not sure.

I don't see any -1 likes in the database, so it really is just a front end issue there.

[btbonval]

I ran another sync update. I'm a little concerned about the desynchronization as some of the users that are heavily implicated don't seem active on the website.

A particular user was associated with 25 like mismatches (in the top 5 mismatches), but that user has almost no association with the site in 2 years and the profile indicates no likes at all. The database suggests the user hasn't logged in since August 2013, but the last synchronization happened after that.

I just checked, the id is the same in users and rusers (checking in case the wrong id was being used to update likes)

[btbonval]

After reviewing pretty heavily, I'm 97% sure that the -1 Likes is an issue of the front end display not completing the requisite two step process.

Ticket for that created here: https://github.com/publiclab/plots2/issues/97

This ticket has a lot about sync syncing synchronization, but that's not really the point of the ticket. I opened a new ticket re: synchronization. https://github.com/publiclab/plots2/issues/98

Closing this ticket.