search

Scripta-Qumranica-Electronica / Scrollery-website

SQE website
MIT License
3 stars 2 forks source link

Client mutations #69

Closed sjones6 closed 6 years ago

sjones6 commented 6 years ago

Figured out the off-by-one error in the positions. Give the add/delete signs a (gentle) whirl. I'm sure there's a number of bugs in here to be ironed out yet but basic behavior is working.

Note: this is into database-mutations. I will try to get the test coverage up tomorrow against that branch and then we can merge everything into master.

coveralls commented 6 years ago

Coverage Status

Coverage increased (+8.1%) to 85.418% when pulling 33f5d0733abe96aa2c4175b98754088fbe82c1eb on client-mutations into b9791e905dc0a302a17634570994b5471b91144d on database-mutations.

sjones6 commented 6 years ago

Just pushed some tests and got coverage up to 79% and change. Will get some more in there and hopefully bump us up into the green.

Bronson-Brown-deVost commented 6 years ago

Sounds great, I am testing the branch out now.

Bronson

On 28. May 2018, at 11:34, Spencer Jones notifications@github.com<mailto:notifications@github.com> wrote:

Just pushed some tests and got coverage up to 79% and change. Will get some more in there and hopefully bump us up into the green.

— You are receiving this because your review was requested. Reply to this email directly, view it on GitHubhttps://github.com/Scripta-Qumranica-Electronica/Scrollery-website/pull/69#issuecomment-392474850, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AC0NoP_JXfMsc_X_5HpeIG49fsxTFMjjks5t28SVgaJpZM4UPQaV.

Dr. Bronson Brown-deVost, PhD Post-Doctoral Researcher Scripta Qumranica Electronica Georg-August-Universität Platz der Göttinger Sieben 2 D-37073 Göttingen Bronson.Brown-deVost@theologie.uni-goettingen.demailto:Bronson.Brown-deVost@theologie.uni-goettingen.de

[cid:C13E71C4-4432-4C07-BE54-67FB2A86747E@goemobile.intern]

Bronson-Brown-deVost commented 6 years ago

Very cool. I ran into one little problem, that perhaps you can think about. If I delete and type new letters somewhat quickly, I can find myself in a situation where a post request is made that has a next_sign_id and/or previous_sign_id that is a UUID from your frontend model and not the actual numeric id in the database. I guess that means that an earlier post request has not yet returned and updated the temporary ids in the model. I am not sure how easily I can handle this in the backend, I would somehow have to access information about the request that is not yet finished. I think it might be easier to deal with on the browser side. What do you think?

sjones6 commented 6 years ago

That's a definite area for improvement. My initial thinking is to buffer requests and only make them every ~500ms or so on change. All changes in that interval would go in one request. Any changes that come in before that request resolves would go in the next request after the first has resolved (presumably less that 500ms but we can make sure the first succeeds before allowing more through).

If I can get some power on the train, I'll write some more tests but my battery is low. Will be in Göttingen in ~2hrs.

Bronson-Brown-deVost commented 6 years ago

There is usually power on the trains, you have to look pretty carefully to find the sockets though. Don't worry about looking odd while searching around. It is more acceptable here to look rather intensely around a train cabin. If you need/want to ask, it is called a Steckdose.

The buffer system sounds like a good solution to me.