| [20:01:31] | <paul121[m]> | oh cool - so maybe we already fixed conflicts with this patch: "Issue #3167287: Always load clients through client ..." |
| [20:01:57] | <paul121[m]> | s/client/the/, s/.../Client Repository service/ |
| [20:04:53] | <mstenta[m]> | maybe - it was back in dec so things may have changed - maybe we can review sometime in the near future |
| [20:05:20] | <mstenta[m]> | i'm curious about the aggregator considerations - but that can wait too |
| [20:05:33] | <mstenta[m]> | signing off here - night! |
| [21:41:17] | * farmBOT has joined #farmos |
| [00:12:04] | <symbioquine[m]> | <mstenta[m]> "symbioquine: when you have a..." <- Looks good as far as I can recall. |
| [01:41:35] | * farmBOT has quit (Ping timeout: 256 seconds) |
| [01:41:58] | * farmBOT has joined #farmos |
| [05:00:11] | * dzfarmer[m] has quit (Quit: You have been kicked for being idle) |
| [05:42:25] | * farmBOT has quit (Ping timeout: 256 seconds) |
| [05:42:48] | * farmBOT has joined #farmos |
| [11:40:29] | <ludwa6[m]> | g'day room: am doing some data admin, and wanting to find & delete any 'Plant types' that don't have any related records in the db. I've got several pages of 'em at https://vdl.farmos.net/admin/structure/taxonomy/manage/plant_type/overview... |
| [11:41:14] | <ludwa6[m]> | ... total 255, but some of these are dupes or spelling mistakes, i can see, which may or may not have related records. Am looking for an easy way to find those that are orphans. Any ideas? |
| [11:46:14] | <paul121[m]> | Trying to think of ways to do the orphan check from the UI or a only a few API queries - not sure if it's possible right now |
| [11:48:35] | <paul121[m]> | You could get all of your plant_type terms, then for each one query for plant assets of that type at `/api/asset/plant?filter[plant_type.id]={UUID}`. If there are none, then you know the plant_type is not being referenced by a plant asset |
| [11:49:46] | <ludwa6[m]> | Sounds good, paul121 ... But where di i find the UUID of a Plant type from that list? |
| [11:50:50] | <ludwa6[m]> | duh... from the URL, obviously. forget i asked <8-)... |
| [11:52:33] | <ludwa6[m]> | It's really strange, tho, i gotta say: first of all, that the 'Plant types' overview page is itself so uniformative... And then clicking any item on that page, brings me to a blank page, despite the fact that i've got a Plant type entered for all my Plant assets. |
| [11:53:47] | <paul121[m]> | you can get your plant types at `api/taxonomy_term/plant_type` :D |
| [11:54:23] | <paul121[m]> | Remember there is a difference between the ID (a integer) and the UUID (much longer) |
| [11:55:08] | <paul121[m]> | I imagine you would be supportive of this PR: https://github.com/farmOS/farmOS/pull/458 |
| [11:55:57] | <ludwa6[m]> | paul121[m]: yes, i've been drooling over that one |
| [11:57:00] | <ludwa6[m]> | since symbioquine shared it in this thread: https://farmos.discourse.group/t/family-relations-among-plants/1194/8 |
| [11:57:10] | <symbioquine[m]> | I really need to dust that one off and get it moving again :) |
| [11:58:46] | <ludwa6[m]> | symbioquine[m]: amen! if there's anything i can do to support the effort (in my non-dev capacity), don't hesitate to ask, mate |
| [12:22:02] | <ludwa6[m]> | Q: how do i modify this request to get more than 50 records returned? https://vdl.farmos.net/api/taxonomy_term/plant_type |
| [12:27:36] | <paul121[m]> | Unfortunately 50 is a hard limit. You'll need to use pagination to specify which page you want |
| [12:27:51] | <paul121[m]> | You can click on the "next" links at the bottom |
| [12:28:43] | <ludwa6[m]> | paul121[m]: ah... you are talking about UI, i guess. I'm trying to do this via ApI |
| [12:29:49] | <paul121[m]> | sorry, I am talking about API. Wasn't sure if you're looking at it in the browser or in code :-) |
| [12:29:49] | <ludwa6[m]> | oh, i see; again: forget the dumb quesitno |
| [12:30:49] | <paul121[m]> | yea, at the bottom: links.next.href |
| [12:44:45] | <mstenta[m]> | paul121 symbioquine I've got a next-step PR ready for eyes if you're interested: https://github.com/farmOS/farmOS/pull/523 |
| [12:45:04] | <mstenta[m]> | (another incremental change - no functional difference - just merges our two existing workflows into one) |
| [13:11:12] | <paul121[m]> | looks good (I guess didn't pass a changelog test?). curious if they could actually be separate workflows but no biggie :-) |
| [13:12:11] | <paul121[m]> | I'm headed out, will be driving most the rest of the day! 👋 |
| [13:13:28] | <symbioquine[m]> | I like that idea too, but I also like the visualization of the full build/test/release/push workflow... |
| [13:13:38] | <mstenta[m]> | thanks paul121 - good points - responding in the PR now - have a nice weekend! |
| [13:50:34] | <FarmerEd[m]> | <paul121[m]> "Unfortunately 50 is a hard limit..." <- I've wondered about this myself, I know Drupal chose 50 for site performance reasons, presumably for sites with higher traffic than a farm management server, would a larger page size make some sense for this sort of application? |
| [14:28:47] | <ludwa6[m]> | <FarmerEd[m]> "I've wondered about this myself,..." <- I'm +1 the idea of higher page limits, but am ignorant as to impact on performance. I know i've induced some server errors by setting up in farmOS UI a complex query and then asking for the full 500 limit... But in case of simple GET request to API, asking only for a single entity that doesn't not involve a join, i don't imagine it would make a great diff, 500 vs 50 records returned. |
| [14:35:21] | <symbioquine[m]> | I'm curious why it makes much difference to you folks? I'd argue that if you're writing code, most cases where more than 50 results could be available also need to be coded to handle >500 results. If that's true, a larger page size won't help to make the code simpler... |
| [14:36:29] | <symbioquine[m]> | Is it a performance problem? |
| [14:37:46] | <symbioquine[m]> | If so, what are you trying to accomplish and how is this acting as a bottleneck? |
| [14:39:29] | <symbioquine[m]> | At the cost of a bit of code complexity, perhaps there's any easy way around the sequential nature of pagination (assuming that's the bottleneck)... |
| [14:40:43] | <symbioquine[m]> | E.g. sharding your queries such that they can be parallelized with each sharded query involving few pages. |
| [14:42:51] | <symbioquine[m]> | For example if logs tend to be evenly distributed over time you could split a query for all logs into N queries one for each year or month. |
| [14:44:42] | <symbioquine[m]> | Similarly asset queries could be sharded on asset I'd ranges or creation/modification timestamp. |
| [14:44:57] | <symbioquine[m]> | s/I'd/ID/ |
| [14:48:35] | <FarmerEd[m]> | Honestly, it's not that big of an issue, more curiosity, just other similar API's I've worked with have larger page sizes. |
| [14:48:36] | <FarmerEd[m]> | At the moment I'm working on a project to sync my farmOS herd data with another database which returns 2000 items per page, which honestly seems excessive, but since I'm only querying my active herd it will never exceed 100 anyway. |
| [14:51:02] | <FarmerEd[m]> | I suppose the one positive of the smaller page size is it made me deal with pagination in my own code sooner rather than later. |
| [14:53:40] | <symbioquine[m]> | I think it also encourages more awareness of the bandwidth/computational cost of "getting everything" from a server. |
| [14:56:48] | <FarmerEd[m]> | That's true too, and is going to be different for self hosted and farmier hosted instances. |
| [14:58:53] | <symbioquine[m]> | In scaled-out services (multiple servers running the same service behind a load balancer) it also makes consistent performance/scaling more feasible. |
| [15:02:34] | <symbioquine[m]> | I.e. if you allow huge page sizes than queries become extra heterogeneous with regard to their performance cost and some servers will get tied up for a long time with big queries - perhaps over utilizing their disk/CPU - while others churn through lots of cheap queries - perhaps saturating their bandwidth more. |
| [15:14:38] | <FarmerEd[m]> | I suppose the question is what is a huge page size? I'm sure Drupal decided on the size to cater for a wide variety of service types with multiple users as well as instances , farm management on the other hand is more likely to have fewer users compared to other services although it is of course still relative to available bandwidth. |
| [19:43:42] | <Noaht[m]> | Could anyone help me figure out this issue? I tried setting up a local instance of farmOS 2.x using the default docker-compose file, but it hasn't been working. I think it's failing to generate the correct files in the www directly, but not sure why. Heres the output message from the farmos/farmos:2.x-dev container.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/f9aef943a5...) |