| [08:42:50] | <symbioquine[m]> | Maybe I'm just being dense, but there's no way to find/cleanup orphaned (unreferenced) quantities in farmOS right? |
| [08:44:53] | <symbioquine[m]> | Entity creation isn't atomic so I think such quantities will get randomly created over time in the event of failures of various sorts part-way through the creation of logs. |
| [09:00:26] | <mstenta[m]> | You're right |
| [09:00:37] | <mstenta[m]> | There's an open issue for this |
| [09:01:13] | <mstenta[m]> | And it's partly why we changed /quantities to /log-quantities |
| [09:01:37] | <mstenta[m]> | To filter orphaned quantities out of the UI |
| [09:04:07] | <mstenta[m]> | The challenge is identifying orphans... if a contrib module adds a quantity field then we don't want to delete those |
| [09:04:36] | <mstenta[m]> | But that's probably solvable |
| [09:04:36] | <symbioquine[m]> | Makes sense |
| [09:04:45] | <mstenta[m]> | Just haven't yet |
| [09:05:04] | <symbioquine[m]> | Going down the rabbit hole of seeing how many I have right now... |
| [09:05:33] | <symbioquine[m]> | Probably more than the average since I run lots of experimental stuff |
| [09:12:30] | <mstenta[m]> | On the bright side, if you know you're only using the core quantity reference on logs, then they are easy to identify and clean up! |
| [09:13:12] | <mstenta[m]> | Here is the open issue FYI: https://github.com/farmOS/farmOS/issues/775 |
| [09:13:27] | <mstenta[m]> | The title is more specific because that's where it was first discovered |
| [09:15:36] | <mstenta[m]> | If you need help with a query/php script to run via Drush I can help |
| [09:17:07] | <mstenta[m]> | I thought I had one already on that issue but maybe not |
| [09:17:33] | <mstenta[m]> | Oh be mindful of this consideration too: https://github.com/farmOS/farmOS/issues/775#issuecomment-1894529170 |
| [09:21:22] | <symbioquine[m]> | mstenta[m]: > So we would need to make sure we don't delete a quantity that's referenced by a previous log revision. |
| [09:21:22] | <symbioquine[m]> | The plot thickens! |
| [09:22:29] | <symbioquine[m]> | Next question: will Drupal throw an error if you try and delete an entity referenced by a previous revision? |
| [09:22:33] | <symbioquine[m]> | I'm guessing not |
| [09:23:10] | <mstenta[m]> | The only protection we have against deletion is from https://www.drupal.org/project/entity_reference_integrity |
| [09:23:35] | <mstenta[m]> | So it depends on that... I kinda suspect it does not protect against this particular case |
| [09:23:37] | <symbioquine[m]> | All kinds of things get messy if you're trying to ensure all possible combinations of revision reversion are valid/possible too 🧐 |
| [09:24:19] | <mstenta[m]> | Yes true... related: https://github.com/farmOS/farmOS/pull/1004 |
| [09:24:45] | <mstenta[m]> | We've essentially disabled reverting revisions |
| [09:24:48] | <mstenta[m]> | (in 4.x) |
| [09:25:39] | <symbioquine[m]> | Did reverting create a new revision (like in Git)? |
| [09:26:02] | <symbioquine[m]> | Or did it just adjust the "pointers" so the old revision was the current one? |
| [09:26:20] | <symbioquine[m]> | (Sorry if this is explained in the issue) |
| [09:26:32] | <mstenta[m]> | Hmm good question... I forget, but yes I think it creates a new revision? |
| [09:27:15] | <mstenta[m]> | That issue was specifically about how reverting revisions could create invalid entities... so I don't know if we were worrying about that question specifically |
| [09:27:16] | <symbioquine[m]> | mstenta[m]: In that case, then there could be an argument for making it "recursive" in the case of entity references. |
| [09:28:04] | <mstenta[m]> | Yea... gets complicated quick |
| [09:28:29] | <mstenta[m]> | (As with Git... potential for "conflicts"?) |
| [09:28:30] | <symbioquine[m]> | I assume it might create a new revision for the (say log) entity, but that could be pointing at old revisions of the related quantities? |
| [09:28:48] | <symbioquine[m]> | Oh wait |
| [09:28:59] | <symbioquine[m]> | We already have immutable quantities? |
| [09:29:19] | <mstenta[m]> | Heh... I think I was just starting to have similar thoughts... |
| [09:29:22] | <symbioquine[m]> | (sorry just thinking out loud here) |
| [09:29:49] | <mstenta[m]> | Can we consider "quantity revisions" essentially the same thing as "immutable quantities"? |
| [09:30:14] | <mstenta[m]> | (If the revisions themselves are immutable?) |
| [09:32:42] | <symbioquine[m]> | I guess so |
| [09:42:24] | <symbioquine[m]> | Interesting tidbit: if you want to find your material quantities the query is a little obtuse: https://example.farm/api/log/input?filter[quantity.quantity_type.meta.dr... |
| [09:42:37] | <symbioquine[m]> | Took me a while to figure out that .meta.drupal_internal__target_id part. |
| [09:42:51] | <symbioquine[m]> | s//`/, s/input/{log_type}/, s//`/ |
| [09:47:29] | <symbioquine[m]> | https://gist.github.com/symbioquine/7a67edccd32ea634cc5bf0597f9c7f31 |
| [09:49:50] | <symbioquine[m]> | Haven't gone down the past revisions rabbit hole yet. |
| [09:51:45] | <mstenta[m]> | I think that will just involved querying references in log_revision__quantity |
| [09:51:52] | <mstenta[m]> | s/involved/involve/, s//`/, s//`/ |
| [09:52:12] | <mstenta[m]> | Oh but that's via SQL... not API... |
| [09:52:30] | <symbioquine[m]> | Yeah, I haven't done anything yet with revisions via the API... |
| [09:52:39] | <symbioquine[m]> | Just looking at https://www.drupal.org/docs/core-modules-and-themes/core-modules/jsonapi... now |
| [09:53:10] | <mstenta[m]> | log__quantity table is the link between log and quantity entities, with only the current revision. log_revision__quantity is the same, but has a row for each revision. |
| [09:53:25] | <symbioquine[m]> | ACTION uploaded an image: (41KiB) < https://matrix.org/oftc/media/v1/media/download/ATLjSWqLk0iWkyOISkA2figP... > |
| [09:57:36] | <symbioquine[m]> | I don't see anything like a previous_revision_id field on the entities returned by the API either so I suspect that it's not possible to discover/iterate previous revisions through the API. |
| [09:57:55] | <mstenta[m]> | hmm yea I don't think there is |
| [09:58:13] | <symbioquine[m]> | Obviously that would also be terribly inefficient too, but just starting with "is it possible" |
| [09:59:19] | <mstenta[m]> | I ran into a strange issue with revisions recently that led me to learn some new things about their complexity... |
| [09:59:40] | <mstenta[m]> | moreso when content translations are involved... |
| [09:59:59] | <symbioquine[m]> | symbioquine[m]: Basically blocked on https://www.drupal.org/project/drupal/issues/3009588 |
| [10:00:00] | <mstenta[m]> | but also that core uses the phrase "default revision" instead of "current revision" |
| [10:00:25] | <mstenta[m]> | because revisions are also used for planned updates... when it comes to content moderation, for example |
| [10:00:25] | <symbioquine[m]> | Coming back to the use-case of Drupal as a CMS |
| [10:00:30] | <symbioquine[m]> | Yeah |
| [10:00:33] | <mstenta[m]> | (drafting changes to web pages / blog posts /etc) |
| [10:01:06] | <mstenta[m]> | and then yea... the whole content translation aspect... each revision can "affect" translations or not... |
| [10:01:34] | <mstenta[m]> | thankfully we don't have to worry about that dimension in farmOS (we only care about interface and config translation in the core farm_l10n module... not content translation) |
| [10:01:48] | <mstenta[m]> | But maybe worth seeing this: https://github.com/farmOS/farmOS/pull/1041 |
| [10:02:03] | <mstenta[m]> | That was my recent rabbit hole 😅 |
| [10:08:32] | <symbioquine[m]> | <mstenta[m]> "But maybe worth seeing this..." <- Seems like a bit of a hack to keep using that revisions UI if the intent is that it's only meant to show revisions that have translatable changes - when we'll never have translatable (content) changes. |
| [10:08:40] | <symbioquine[m]> | But probably a reasonable move short-term at least. |
| [10:09:07] | <symbioquine[m]> | s/short-term/to/, s/at/mark/, s/least/them as translatable/ |
| [10:09:48] | <symbioquine[m]> | It's surprising that the UI has that condition though... |
| [10:10:09] | <mstenta[m]> | My reasoning is: if we don't use content translations, then ALL revisions should be displayed. |
| [10:10:17] | <mstenta[m]> | None should be filtered. |
| [10:10:21] | <symbioquine[m]> | I'm imagining even in the CMS case that you might have an "article photos" field that's not translatable, but you'd still want to be able to manage the revisions for the article when those photos change. |
| [10:10:48] | <symbioquine[m]> | but if I'm understanding correctly, that's not supported by Drupal. |
| [10:10:52] | <mstenta[m]> | IMO it's a bug that it won't show the "current revision" if it ends up marked as "not affecting translation" |
| [10:11:09] | <mstenta[m]> | We don |
| [10:12:02] | <mstenta[m]> | Yea, I get the sense that some of this logic is just historical baggage |
| [10:12:08] | <mstenta[m]> | And for our use case it doesn't make sense |
| [10:12:27] | <mstenta[m]> | I don't see any reason to hide revisions. |
| [10:12:42] | <mstenta[m]> | If we don't want certain things to be saved as revisions, that's a separate issue. |
| [10:12:48] | <mstenta[m]> | But if we do save revisions, they should show on that page. |
| [10:13:01] | <symbioquine[m]> | Maybe there's some use-case where untranslatable field changes cause a lot of spurious revisions? |
| [10:13:32] | <mstenta[m]> | That would be a separate issue too IMO |
| [10:13:43] | <mstenta[m]> | If a revision is saved in the database, I want to see it in the UI |
| [10:14:01] | <symbioquine[m]> | Yeah, seems reasonable |
| [10:14:34] | <mstenta[m]> | But yea... that is the downside of this change... we may all of a sudden find a lot of extra revisions are being created |
| [10:14:46] | <mstenta[m]> | But that's probably a good thing in the long run, because we can investigate why |
| [10:14:56] | <mstenta[m]> | Right now, they may be happening and we just don't know it |
| [10:15:50] | <symbioquine[m]> | Yeah, I doubt it will be an issue for our use-case. Just trying to imagine a reasonable explanation for why you'd want that logic in the "CMS for a website" use-case. |
| [10:16:53] | <mstenta[m]> | Yea... from what I've gathered, it's basically: |
| [10:17:40] | <mstenta[m]> | "I am looking at the english version of this node, so only show me the revisions that affect the english version" |
| [10:18:00] | <symbioquine[m]> | weird |
| [10:18:17] | <symbioquine[m]> | Seems like you'd just want tabs for each language or something |
| [10:18:20] | <mstenta[m]> | And then if you change to the french version, it would only show the ones that affect french. |
| [10:18:30] | <symbioquine[m]> | I guess |
| [10:18:32] | <mstenta[m]> | Yea... I think @catch proposed that exact solution... |
| [10:18:37] | <mstenta[m]> | (core maintainer) |
| [10:19:11] | <mstenta[m]> | > Overall I think the revision tab should show all edits to a node regardless of affected language. For example how else would you undo adding a translation except reverting to the revision just before? We could then have a per-language filter on the page to show only affected languages. Or two tab |
| [10:19:18] | <mstenta[m]> | https://www.drupal.org/project/drupal/issues/2722307 |
| [10:20:28] | <symbioquine[m]> | Left a comment on https://github.com/farmOS/farmOS/pull/1041 |
| [10:25:36] | <mstenta[m]> | Thanks! Good point... pushing fixup... |