| [01:36:21] | * polo has joined #farmos |
| [01:51:16] | * polo has quit (Ping timeout: 265 seconds) |
| [02:01:04] | * Guest9599 has joined #farmos |
| [02:01:39] | * Guest9599 has quit (Changing host) |
| [02:01:39] | * Guest9599 has joined #farmos |
| [02:01:42] | * Guest9599 is now known as polo |
| [02:03:52] | * polo has quit (Remote host closed the connection) |
| [02:04:33] | * polo has joined #farmos |
| [02:09:24] | * polo has quit (Ping timeout: 264 seconds) |
| [02:10:22] | * polo has joined #farmos |
| [02:10:27] | * polo has quit (Changing host) |
| [02:10:27] | * polo has joined #farmos |
| [02:17:17] | * farmBOT has joined #farmos |
| [03:02:47] | * polo has quit (Quit: Textual IRC Client: www.textualapp.com) |
| [03:03:37] | * owsley_ has joined #farmos |
| [03:04:44] | * owsley_ has quit (Client Quit) |
| [03:05:09] | * polo has joined #farmos |
| [03:11:09] | * owsley_ has joined #farmos |
| [03:37:40] | * polo has quit (Ping timeout: 244 seconds) |
| [03:38:11] | * owsley_ has quit (Ping timeout: 244 seconds) |
| [03:40:26] | * polo has joined #farmos |
| [03:40:40] | * polo has quit (Changing host) |
| [03:40:40] | * polo has joined #farmos |
| [03:49:12] | * polo has quit (Ping timeout: 265 seconds) |
| [03:49:14] | * Guest4002 has joined #farmos |
| [03:49:24] | * Guest4002 has quit (Changing host) |
| [03:49:24] | * Guest4002 has joined #farmos |
| [03:49:28] | * Guest4002 is now known as polo |
| [03:53:51] | * polo has quit (Client Quit) |
| [03:54:43] | * polo has joined #farmos |
| [04:10:51] | * polo has quit (Quit: Textual IRC Client: www.textualapp.com) |
| [04:11:47] | * Guest9691 has joined #farmos |
| [04:11:58] | * Guest9691 has quit (Changing host) |
| [04:11:58] | * Guest9691 has joined #farmos |
| [04:12:11] | * Guest9691 is now known as polo |
| [04:12:31] | * polo has quit (Client Quit) |
| [04:12:50] | * polo has joined #farmos |
| [04:12:54] | * polo has quit (Changing host) |
| [04:12:54] | * polo has joined #farmos |
| [04:14:26] | * polo has quit (Client Quit) |
| [05:00:11] | * perfectinfoseeke has quit (Quit: You have been kicked for being idle) |
| [08:36:42] | * Guest7284 has joined #farmos |
| [08:37:41] | * Guest7284 has quit (Changing host) |
| [08:37:41] | * Guest7284 has joined #farmos |
| [08:37:45] | * Guest7284 is now known as polo |
| [08:53:31] | * polo has quit (Quit: Textual IRC Client: www.textualapp.com) |
| [08:53:59] | * polo has joined #farmos |
| [09:28:04] | * polo is now known as money |
| [09:29:27] | * money is now known as polo |
| [09:29:28] | * polo is now known as money |
| [09:29:44] | * money is now known as polo |
| [09:29:52] | * polo is now known as money |
| [09:30:27] | * money is now known as polo |
| [09:30:27] | * polo has quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| [09:31:40] | * Guest8711 has joined #farmos |
| [09:36:17] | * Guest8711 has quit (Ping timeout: 250 seconds) |
| [10:31:13] | <symbioquine[m]> | woot! https://www.drupal.org/project/subrequests/issues/3059582#comment-14691256 |
| [11:46:58] | <mstenta[m]> | awesome!! |
| [11:48:23] | <mstenta[m]> | and a new release! |
| [11:49:06] | <mstenta[m]> | symbioquine paul121 PR for preventing circular asset location, per our earlier discussion: https://github.com/farmOS/farmOS/pull/568 |
| [11:53:00] | <paul121[m]> | You've been busy this morning :D |
| [11:59:44] | <mstenta[m]> | In thinking about these circular reference validators... I think I can imagine another situation that could lead to them... which might warrant a follow up |
| [12:00:32] | <mstenta[m]> | Is it possible to save a "valid" log (that does not create a circular relationship), and then delete or revert another log that passively "invalidates" it? |
| [12:01:16] | <mstenta[m]> | > delete or revert another log |
| [12:01:16] | <mstenta[m]> | actually edit/delete/revert |
| [12:01:36] | <mstenta[m]> | this is an edge case, and I think we can at least start with this PR... but it got me thinking |
| [12:02:25] | <mstenta[m]> | writing some tests would be a good way to understand this better |
| [12:04:36] | <mstenta[m]> | this started with the question: does "reverting" an entity revision run entity validation on it? otherwise it might be possible to "revert" to a state that would be considered "invalid" were it to be manually saved now |
| [12:06:00] | <paul121[m]> | Ah interesting |
| [12:06:40] | <mstenta[m]> | I think what's unique about these validators is they aren't just looking at data on the entity that's being saved... they are also looking at the state of current relationships between other entities |
| [12:07:39] | <symbioquine[m]> | Did you figure out whether those possible race conditions I pointed out are real? |
| [12:08:09] | <mstenta[m]> | No we should investigate that too... I still have the @todo |
| [12:08:49] | <mstenta[m]> | I figure we get these initial PRs in which provide "basic" protection, which is better than none... then investigate the edgier cases |
| [12:09:14] | <symbioquine[m]> | Yeah, some of the race conditions may not be completely preventable. |
| [12:09:29] | <mstenta[m]> | Yea :-/ |
| [12:09:36] | <mstenta[m]> | Some of these circular relationships may be hard to prevent too |
| [12:09:42] | <symbioquine[m]> | Might be best to also have "query side" protections against - and or UX for - circular references... |
| [12:09:48] | <mstenta[m]> | But the most basic ones are easy enough to defend against |
| [12:10:20] | <mstenta[m]> | The tricky part is thinking through all the possible things that can change to cause them to become invalid |
| [12:10:25] | <symbioquine[m]> | yeah |
| [12:10:27] | <mstenta[m]> | eg: what if you shuffle around the timestamps of a bunch of movement logs |
| [12:10:47] | <symbioquine[m]> | Do migrations honor those integrity checks? |
| [12:10:55] | <mstenta[m]> | Yes |
| [12:10:59] | <symbioquine[m]> | cool |
| [12:11:16] | <mstenta[m]> | that's something we worked on before beta... glad we did |
| [12:11:43] | <mstenta[m]> | (led to some headaches cleaning up old data... but better to clean it up!) |
| [12:13:29] | <mstenta[m]> | > eg: what if you shuffle around the timestamps of a bunch of movement logs |
| [12:13:29] | <mstenta[m]> | hmm 🤔 this makes me think that these validation checks need to be taking the timestamp of the log they are validating into account |
| [12:14:01] | <mstenta[m]> | otherwise if you edit an older log, it will be validated against the current state of things, which is not what you want |
| [12:16:44] | <mstenta[m]> | this would require adding a `$timestamp` parameter to all the location (and group) service methods |
| [12:17:11] | <mstenta[m]> | which would be great |