| [19:00:54] | <holz[m]> | Hello, new here! I have a noob question, and hope this is the place for it, if not, please redirect me ~ |
| [19:00:54] | <holz[m]> | I am making a nodejs app to integrate telegram with farmos. I am using axios to authenticate with oauth2 password credentials grant and axios.POST to retrieve data from /log.json. However I am getting an error code 500 "Service unavailable (with message)" for the /log.json endpoint, while the /farm.json endpoint works fine for me. Any pointers? |
| [19:03:39] | <mstenta[m]> | Hi holz |
| [19:04:17] | <mstenta[m]> | Are you self hosting? Or using Farmier? |
| [19:04:51] | <mstenta[m]> | If self, you can see the 500 error message at /admin/reports/dblog |
| [19:05:44] | <mstenta[m]> | You mention you're using POST to retrieve data...POST is for creating new records, not retrieving |
| [19:05:53] | <mstenta[m]> | GET is for retrieving. Maybe that's the issue? |
| [21:38:00] | <paul121[m]> | <symbioquine[m] "huh, I'd be curious to hear what"> yeah, in this case there are a couple hundred field areas that are long-term plantings (orchard, hops, blueberries). Having to create the movement & assign plantings to areas just to display them on the map with all the records was a hassle. We ended up with almost a 1-1 areas->plantings, each with the same name, which is fairly confusing |
| [21:40:23] | <paul121[m]> | The farm didn't have the concept of Areas vs Plantings in their internal record keeping, it was all the same. Not to say that is ideal... even if plantings cycle through an area every 20 years, there is still reason to keep records of what is in the same spatial area... just becomes more long-term thinking! |
| [21:42:18] | <paul121[m]> | But now it sounds like they are hoping to use Areas in their record keeping, since they do actually have multiple plantings/varieties in the same area, they just didn't have the ability to track with that granularity before! |
| [21:45:32] | <paul121[m]> | But even then, having geometries on the planting will still be useful. They are interested in looking at the "planted area" of their plantings. Basically an orchard might only occupy 90% of a field, once you take out the perimeter, roads, etc. Using this value is important when analyzing inputs into the area |
| [21:50:07] | <paul121[m]> | I guess there's an argument that an movement log geometry could still capture this "planted area" within the larger area... but for something that doesn't change, its just one less complication. I think theres a fair argument for "usability" in this context, even if it means a less ideal data structure. If both options and limitations are explained, then it seems OK to let the user choose? |
| [21:52:14] | <paul121[m]> | I think mstenta has mentioned the "current location" geometry could either be 1) derived from movement logs (if they exist) or 2) default to the asset's geometry |
| [21:53:46] | <paul121[m]> | * I guess there's an argument that a movement log geometry could still capture this "planted area" within the larger area... but for something that doesn't change, its just one less complication. I think there is a fair argument for "usability" in this context, even if it means a less ideal data structure. After all, if both options and limitations are explained, then it seems OK to let the user choose? |
| [21:54:16] | <paul121[m]> | if a user tries to update the asset geometry while it has a movement logs defined, a warning/info message could be displayed |
| [21:54:58] | <paul121[m]> | * if a user tries to update the asset geometry while it has movement logs defined, a warning/info message could be displayed |
| [00:27:31] | <symbioquine[m]> | I might be wrong, but that sounds more like a UI/UX issue more than a data modeling one. Personally, I'd argue for keeping the data model simpler and improve the interface to disambiguate or even hide the redundancy in the 1:1 case. |
| [00:33:09] | <symbioquine[m]> | <paul121[m] "I guess there's an argument that"> It's only a complication if the UX directly exposes the raw data model to the end user. Why make the "user choose" when you can have a sane opinionated single path that handles both the 1:1 case and the N:N cases? |
| [06:38:17] | * farmBOT has joined #farmos |
| [07:19:18] | <mstenta[m]> | perhaps we should get these thoughts into an issue |
| [07:20:36] | <mstenta[m]> | symbioquine: i was of the same mind as you originally, but have been coming around to the idea of "intrinsic geometry" |
| [07:20:45] | <mstenta[m]> | i'll start a thread so we can document all these thoughts... |
| [07:22:22] | <mstenta[m]> | but yea... this is a great example of something that cuts right to the core of that revisions vs logs question! |
| [07:31:35] | <mstenta[m]> | in fact, i may just resurrect that issue and put thoughts into there |
| [07:36:54] | <mstenta[m]> | it also relates to this one (which Nick @BOTLFarm reminded me of in his recent forum comment about time tracking): https://www.drupal.org/project/farm/issues/2630218 |
| [08:46:31] | <mstenta[m]> | (oh boy this is turning into an essay - sorry in advance symbioquine and paul121 ) :-) |
| [09:11:33] | <holz[m]> | > You mention you're using POST to retrieve data...POST is for creating new records, not retrieving |
| [09:11:33] | <holz[m]> | Yes problem is because i wasn't using GET. Thanks for the quick reply!! |
| [09:11:33] | <holz[m]> | I am using Farmier for hosting. |
| [09:12:20] | <mstenta[m]> | Ah great! Glad it's working! |
| [10:00:52] | <mstenta[m]> | symbioquine paul121 https://www.drupal.org/project/farm/issues/3182176 |
| [10:01:26] | <mstenta[m]> | I made key points BOLD, if you want to just skim those |
| [10:01:38] | <mstenta[m]> | Hopefully it all makes sense! Eager to hear your thoughts! |
| [11:17:12] | <paul121[m]> | <symbioquine[m] "I might be wrong, but that sound"> Yeah I agree the confusion with duplicate names is more of a UI/UX issue. For 2.x we're making a more custom UI so we can hide this. But in core farmOS there isn't the option |
| [11:18:55] | <symbioquine[m]> | <paul121[m] "Yeah I agree the confusion with "> I'm reading the drupal.org issue now and I'm starting to understand the argument for having intrinsic geometry better... :) |
| [11:21:32] | <paul121[m]> | 👍️ the ability to have any asset type act as a "location" is something I don't think we talked about in chat, nor on the call yesterday. but an important piece to intrinsic geometry, I think |
| [11:22:12] | <paul121[m]> | mstenta: a question I want to ask here before polluting the issue with comments :) |
| [11:25:48] | <paul121[m]> | with what you described, is this possible: A plant asset w/ location & movable set to TRUE. I want to assign the plant asset as being within another area (or any "location"), but use the Plant asset's intrinsic geometry. Is this silly? I think there is a use case. |
| [11:25:48] | <paul121[m]> | I want the plant asset located in an area, but don't want to update the "plant geometry" with movement logs - this is "intrinsic" to the asset, and can be captured with revisions. BUT I want to keep record of that it lives in this other location |
| [11:26:28] | <paul121[m]> | * with what you described, is this possible: A plant asset w/ location & movable set to TRUE. I want to assign the plant asset as being within another area (or any "location"), but use the Plant asset's intrinsic geometry. Is this silly? I think there is a use case. |
| [11:26:28] | <paul121[m]> | I want the plant asset located in an area, but don't want to update the "plant geometry" with movement logs - this is "intrinsic" to the asset, and can be captured with revisions. BUT I want to keep record that it lives in this other location |
| [11:26:31] | <symbioquine[m]> | I'm not a fan of the delineation quoted in the issue "If the change is specifically for one asset: use revisions.⏎⏎ If the change can apply to multiple assets: use logs." In my mind, logs serve a much broader purpose of providing a place to put lots of other data related to a change - like notes, photos, associated measurements, etc. It's not just a "one vs many" question. |
| [11:27:06] | * pcambra[m] has joined #farmos |
| [11:27:36] | <mstenta[m]> | symbioquine: yea... that idea was old... i don't necessarily stand by it either... but it still may be useful in some contexts to think about |
| [11:27:47] | <symbioquine[m]> | cool |
| [11:27:52] | <mstenta[m]> | i tried to avoid making that a statement of truth |
| [11:27:57] | <symbioquine[m]> | :) |
| [11:28:17] | <mstenta[m]> | ... reading your question paul121 ... |
| [11:29:58] | <paul121[m]> | symbioquine: still thinking more about this concept you brought up yesterday, where "logs are used to represent everything". I like the granularity & flexibility but don't like the complexity haha |
| [11:30:37] | <paul121[m]> | but obviously there are some limitations when logs are not used (as you mentioned with the gender, and more relevant with movements) 🤔 |
| [11:31:52] | <mstenta[m]> | yea i think this "intrinsic geometry" question cuts right to the heart of the "revision vs log" ideas :-) |
| [11:32:22] | <symbioquine[m]> | <paul121[m] "but obviously there are some lim"> Also there are limitations when moving between data models - for example does relying on "revisions" mean that all data models with which farmOS must interoperate must also have revisions for parity? |
| [11:32:43] | <paul121[m]> | very true.\ |
| [11:32:46] | <symbioquine[m]> | Whereas, supporting logs is a core requirement regardless. |
| [11:32:48] | <paul121[m]> | * very true. |
| [11:33:28] | <mstenta[m]> | i think the distinction comes down to: does there need to be an explicit record of this change, in a record keeping sense |
| [11:33:42] | <mstenta[m]> | for "intrinsic" properties, the answer is "no" |
| [11:33:50] | <mstenta[m]> | and therefore the extra metadata of a log is not required |
| [11:33:57] | <mstenta[m]> | a revision note is all that's needed |
| [11:34:20] | <mstenta[m]> | "geometry" is a bit of a unique case in this regard... |
| [11:34:27] | <mstenta[m]> | because it IS intrinsic for some assets, but not for others |
| [11:34:49] | <mstenta[m]> | and let's consider the "changing bed size" case in that regard... |
| [11:34:56] | <mstenta[m]> | you have a choice: |
| [11:35:17] | <mstenta[m]> | if you need to record metadata around the change of that, then perhaps a log is what you want |
| [11:35:29] | <mstenta[m]> | or, perhaps you archive the bed and create a new one |
| [11:35:50] | <mstenta[m]> | but if you're just "correcting" a bed size (like if you drew it a little too small), then a revision is all you need |
| [11:36:08] | <mstenta[m]> | so using logs is explicitly about creating "meaning" around the change |
| [11:36:28] | <mstenta[m]> | (does this make sense?) |
| [11:36:48] | <mstenta[m]> | so in some cases - it's actually a choice you need to make |
| [11:37:21] | <mstenta[m]> | is it valuable to have the details of a change recorded as an explicit log? and if not, then maybe it's just a revision to an existing asset/log |
| [11:37:30] | <symbioquine[m]> | Yeah, that's a great way to put it. Also it helps with the data model interoperability question - that "meaning" needs to transcend data models, but the history of all the "fixup changes" might not. |
| [11:37:32] | <mstenta[m]> | (remember too: logs can have their own revisions) :-) |
| [11:38:02] | <mstenta[m]> | paul121: i haven't forgotten your question... it's a good one... and tricky haha |
| [11:38:11] | <paul121[m]> | one little thought: With drupal revisions, we could use revisions to display "what was the geometry at this timestamp", yes? but with what you described, we would rather use movements/logs to model this? |
| [11:38:52] | <mstenta[m]> | hmm yea... i think we'd probably want to leave revisions out of the "geometry at a given timestamp" logic... |
| [11:38:55] | <mstenta[m]> | just for simplicity |
| [11:39:03] | <mstenta[m]> | but maybe it would still be valuable to include them? |
| [11:39:04] | <paul121[m]> | in other words, farmOS core won't use that. but I could.... |
| [11:39:06] | <mstenta[m]> | it's a good question |
| [11:39:36] | <paul121[m]> | especially if I'm not as concerned about interop with other systems |
| [11:41:17] | <mstenta[m]> | (i want to go back to your earlier question paul121 but don't want to split the convo... so maybe i'll wait until we're at a good breaking point) |
| [11:42:58] | <paul121[m]> | <mstenta[m] "paul121: i haven't forgotten you"> np. I *think* its just a matter of checking "is it movable? NO -> does it have movement logs? NO -> does it have intrinsic geometry? Yes/No" |
| [11:43:23] | <paul121[m]> | (already typed that but feel free to continue on...haha) |
| [11:43:34] | <mstenta[m]> | ah! good question re: hierarchy |
| [11:43:38] | <mstenta[m]> | so that will actually be based on the "Parent" field |
| [11:43:51] | <mstenta[m]> | which will also exist on Land/Structure/Water assets |
| [11:44:23] | <mstenta[m]> | and the "area hierarchy" will essentially be built from assets with the "Location" boolean TRUE, using their Parent fields |
| [11:44:47] | <mstenta[m]> | i don't think we should worry about tracking changes to hierarchy over time via logs... |
| [11:44:49] | <paul121[m]> | ohhh cool. so the hierarchy won't show the current location of assets? (this was my confusion) |
| [11:44:56] | <mstenta[m]> | (though i did consider that too) |
| [11:45:25] | <paul121[m]> | makes sense. I think that solves my question... I just assign a parent to my plant asset |
| [11:45:32] | <mstenta[m]> | right - yea the "area hierarchy" is sort of a separate thing... |
| [11:45:33] | <mstenta[m]> | more of a meta understanding of the relationship of "location" assets, in my mind |
| [11:45:46] | <mstenta[m]> | oh right! yes! |
| [11:45:48] | <mstenta[m]> | that does solve your use case! |
| [11:45:52] | <mstenta[m]> | :-D |
| [11:47:06] | <symbioquine[m]> | It might not be in question here, but I want to emphasize the importance of plantings having their own geometry which can be more specific than the bed/field/etc; |
| [11:47:13] | <symbioquine[m]> | ACTION uploaded an image: image.png (73KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/oODUKRsaSruunYar... > |
| [11:47:43] | <mstenta[m]> | indeed! (nice image!) |
| [11:48:13] | <mstenta[m]> | so in this updated model... that could still work the same way via movement logs |
| [11:48:37] | <mstenta[m]> | but it would actually ALSO be possible for plantings to NOT have a movement log and just be shown on the map using their "intrinsic" geometry... not sure that would be useful in your context... but it would be possible |
| [11:48:57] | <paul121[m]> | just depends! will the plantings be moving, or no? |
| [11:49:17] | <mstenta[m]> | but yea as this all relates to maps... i'm excited to think about actually merging the asset geometry maps into the area geometry maps... so all is visible at the same time |
| [11:49:31] | <mstenta[m]> | regardless of where its coming from |
| [11:50:45] | <paul121[m]> | basically every asset'c "current location" would be calculated & shown on the map then? |
| [11:50:47] | <symbioquine[m]> | <mstenta[m] "but it would actually ALSO be po"> At least for my use-case having the explicitness of the seeding log capturing all the details of the initial planting event is useful I can't see the log going away anyway. |
| [11:51:05] | <paul121[m]> | * basically every asset's "current location" would be calculated & shown on the map then? |
| [11:51:10] | <mstenta[m]> | yes exactly. i think that will still be true for most planting use-cases |
| [11:51:43] | <paul121[m]> | mmm yes. seeding log as a movement log? |
| [11:51:54] | <mstenta[m]> | perhaps in something like "natural forest management" it would be more convenient to use the intrinsic geometry, because there is no actual "seeding/transplanting" event |
| [11:52:15] | <mstenta[m]> | or marking existing trees on a property perhaps |
| [11:52:29] | <mstenta[m]> | which were not planted by you |
| [11:53:28] | <symbioquine[m]> | Yeah, that makes sense in a way... |
| [11:54:11] | <symbioquine[m]> | You could also address that through the UX by having the tooling ask for the estimated age of the tree and automatically create a "backdated imputed seeding log" or something :) |
| [11:54:20] | <mstenta[m]> | true true |
| [11:56:07] | <mstenta[m]> | (aside: i need to sign off in a few minutes here - but wanted to thank both of you for taking the time to talk through all this today! this is the next big thing to code in 2.x, so it's really helpful!) |
| [11:56:29] | <symbioquine[m]> | <mstenta[m] "perhaps in something like "natur"> I can see an argument for keeping it simple though - especially if there's a way out for folks who later realize they're going to transplant that tree, or perhaps are given the forestry records and (somehow) have bandwidth to put in the key original planting information after the fact. |
| [11:56:57] | <mstenta[m]> | yes true.. i was just thinking about that as well |
| [11:57:20] | <mstenta[m]> | i suppose it would still work to just start using movement logs for an asset at any point after it's created |
| [11:57:47] | <mstenta[m]> | maybe it just requires unchecking "this asset is moveable" so that it looks for movement logs instead |
| [11:58:03] | <mstenta[m]> | i'm still not 100% in love with the idea of adding a "this asset is moveable" checkbox... but it seems like it's necessary |
| [11:58:17] | <mstenta[m]> | and maybe it's good to have that explicit distinction in the model |
| [11:58:24] | <mstenta[m]> | i dunno |
| [11:58:52] | <mstenta[m]> | we DO need the "this asset is a location" checkbox, i think... that feels more certain |
| [11:59:12] | <mstenta[m]> | i tried to think through if that would be enough, but i think both might be needed (per what i described in that issue) |
| [11:59:37] | <symbioquine[m]> | <mstenta[m] "i'm still not 100% in love with "> Is this primarily intended as an optimization? |
| [11:59:50] | <symbioquine[m]> | i.e. don't query all the logs for location if we don't have to. |
| [12:00:06] | <mstenta[m]> | unless we just say "all assets have a geometry field, but it will be ignored if there are movements" |
| [12:00:20] | <mstenta[m]> | i think it's maybe more of a UI thing... to avoid confusion |
| [12:00:32] | <symbioquine[m]> | huh |
| [12:00:40] | <mstenta[m]> | eg: if you have an asset that has intrinsic geometry, but also has movements, and you edit that asset... seeing hte geometry field would be pretty confusing |
| [12:00:43] | <symbioquine[m]> | Want to hear more, but I don't want to keep you... :) |
| [12:00:58] | <mstenta[m]> | but i suppose we could also just automatically hide it if there are movements... |
| [12:01:28] | <symbioquine[m]> | <mstenta[m] "but i suppose we could also just"> Or just indicate that it is superceded by X log(s). |
| [12:02:05] | <mstenta[m]> | yea.... |
| [12:02:24] | <mstenta[m]> | i would really love to extra boolean if we can |
| [12:02:38] | <mstenta[m]> | oh... one other thing to mention regarding the API... which i sort of touched on in the issue... |
| [12:02:44] | <mstenta[m]> | in 2.x we'll be using JSON:API |
| [12:03:14] | <mstenta[m]> | so an asset will have `asset.attributes` and `asset.relationships`, but we also have the ability to put things in `asset.meta` |
| [12:03:29] | <symbioquine[m]> | <mstenta[m] "i would really love to extra boo"> I assume this should be "i would really love to **avoid the** extra boolean if we can"? |
| [12:03:45] | <mstenta[m]> | yes haha |
| [12:03:58] | <mstenta[m]> | https://jsonapi.org/format/#document-resource-object-attributes |
| [12:04:01] | <mstenta[m]> | https://jsonapi.org/format/#document-resource-object-relationships |
| [12:04:40] | <mstenta[m]> | https://jsonapi.org/format/#document-meta |
| [12:04:44] | <mstenta[m]> | so... |
| [12:05:00] | <mstenta[m]> | the "intrinsic geometry" WILL appear naturally under `asset.attributes.geometry` |
| [12:05:20] | <mstenta[m]> | but, the thought is: we could put the "calculated" geometry in `asset.meta.geometry` |
| [12:05:43] | <mstenta[m]> | it might be a bit confusing at first, to a new API user seeing both... so we'll want to be sure to document that well |
| [12:05:51] | <mstenta[m]> | but: i think it also makes it nice and explicit |
| [12:06:13] | <mstenta[m]> | `asset.attributes` will be intrinsic properties, while `asset.meta` will be computed/dynamically generated properties |
| [12:07:18] | <mstenta[m]> | "location" (the "area" that an asset is in) will NOT be an intrinsic property... so there will be `asset.meta.location` (a reference to one or more location assets), but there will NOT be an `asset.attributes.location` |
| [12:07:21] | <mstenta[m]> | if that makes sense |
| [12:08:09] | <mstenta[m]> | and if an asset ONLY has an intrinsic geometry, we can just replicate that directly in `asset.meta.geometry` - so from an API user's perspective, you just always use that one to get the asset's geometry |
| [12:08:21] | <mstenta[m]> | regardless of how that geometry is being stored/recorded |
| [12:08:46] | <paul121[m]> | would be cool for the hierarchy to be reflected in `asset.meta.location`, too |
| [12:09:01] | <paul121[m]> | although `asset.attrubutes.parent` would display this as well.. |
| [12:09:13] | <paul121[m]> | * although `asset.attributes.parent` would display this as well.. |
| [12:09:16] | <mstenta[m]> | oh interesting |
| [12:09:30] | <mstenta[m]> | hmmm yea i see what you mean though |
| [12:09:47] | <mstenta[m]> | (going back to the use-case you described originally paul121 ) |
| [12:11:10] | <mstenta[m]> | we can figure out what makes sense for that :-) |
| [12:11:35] | <mstenta[m]> | the "computed" meta attributes will be a whole thing |
| [12:11:56] | <mstenta[m]> | as will the caching ideas... |
| [12:12:31] | <mstenta[m]> | i'm probably going to punt on the caching stuff for now... figuring that it can be added as an layer in between in the near future |
| [12:13:16] | <mstenta[m]> | caching will become more and more necessary the longer people use farmOS, and the more records there are - but we are still in early days :-) |
| [12:13:31] | <mstenta[m]> | ACTION is imagining a farmOS with 20 years worth of records :-) |
| [12:15:08] | <mstenta[m]> | > i would really love to avoid the extra boolean if we can |
| [12:15:08] | <mstenta[m]> | well getting back to this... i can at least get started and see how far i can get without it... maybe it won't be necessary |
| [12:15:26] | <mstenta[m]> | ("asset can be moved") |
| [12:18:49] | <paul121[m]> | makes sense! it does largely seem like a UI issue. as well as a consideration for the API... maybe if there are movement logs, we add an `asset.meta.movable` |
| [17:31:22] | * symbioquine[m] has quit (Ping timeout: 260 seconds) |
| [17:32:04] | * symbioquine[m] has joined #farmos |
| [18:23:52] | * pllagn[m] has quit (Ping timeout: 260 seconds) |
| [18:24:49] | * pllagn[m] has joined #farmos |
