IRC logs for #farmOS, 2021-09-20 (GMT)

[00:29:57]* DanielAshcraft[m has quit (*.net *.split)
[00:29:57]* Cata[m]1 has quit (*.net *.split)
[00:29:57]* jgaehring[m] has quit (*.net *.split)
[00:29:57]* shane_aldrich[m] has quit (*.net *.split)
[00:29:57]* MatrixTravelerbo has quit (*.net *.split)
[00:33:41]* jgaehring[m] has joined #farmos
[00:37:19]* DanielAshcraft[m has joined #farmos
[00:38:02]* Cata[m]1 has joined #farmos
[00:38:02]* shane_aldrich[m] has joined #farmos
[00:41:38]* JulianF[m] has quit (*.net *.split)
[00:41:38]* paul121[m] has quit (*.net *.split)
[00:41:38]* farmtech[m] has quit (*.net *.split)
[00:43:10]* MatrixTravelerbo has joined #farmos
[00:46:02]* paul121[m] has joined #farmos
[00:46:02]* farmtech[m] has joined #farmos
[00:47:49]* JulianF[m] has joined #farmos
[08:24:16]<botlfarm[m]>thanks mstenta. I attempted to open the edit page directly "/taxonomy/term/97/edit" and get the same error. Unless there is another way to get to the edit form I don't think this will work.
[08:24:51]<botlfarm[m]>Any clue where I should be looking in the database itself for this?
[08:24:59]<mstenta[m]>ah ok - well then... to the database! :-P
[08:26:03]<mstenta[m]>in 1.x, area geometry is stored in the `field_data_field_farm_geofield` table
[08:26:18]<mstenta[m]>(as well as the `field_revision_field_farm_geofield` so we'll need to update both)
[08:28:07]<mstenta[m]>probably what we want to do is pinpoint the area that has an issue and then just delete the record from each table
[08:28:13]<mstenta[m]>this will essentially clear out the geometry for that area
[08:28:24]<mstenta[m]>then you should be able to get into the `/edit` page and redraw it
[08:28:45]<mstenta[m]>(always a good idea to take a quick database snapshot first) ;-)
[08:29:09]<mstenta[m]>`SELECT * FROM field_data_field_farm_geofield WHERE entity_type = 'taxonomy_term' AND bundle = 'farm_areas';`
[08:29:40]<botlfarm[m]>Im actually working in an entire backed up copy right now to make sure I'm doing it right before moving on to production. but will defiantly get another backup first.
[08:29:43]<mstenta[m]>that query will filter down to just areas
[08:30:03]<mstenta[m]>i think what you want is: `SELECT * FROM field_data_field_farm_geofield WHERE entity_type = 'taxonomy_term' AND bundle = 'farm_areas' AND entity_id = 97;`
[08:30:23]<mstenta[m]>that should give you the exact geom
[08:30:51]<mstenta[m]>it's stored in Well-Known Binary in the db, so you won't be able to easily read it... i think there's a way to get WKT in a query... i forget
[08:31:05]<mstenta[m]>but if you're OK with just deleting and redrawing then you don't need to read it
[08:31:31]<botlfarm[m]>perfect. Yeah im fine deleting this altogether
[08:31:59]<mstenta[m]>If you feel confident that this is the correct geometry, these two queries will delete it from both tables:... (full message at
[08:32:06]<botlfarm[m]>the odd thing is there are only 9 logs that reference this geometry and they all have closed polygons
[08:32:26]<mstenta[m]>then try going to `/taxonomy/term/97/edit` again
[08:32:38]<mstenta[m]>that is odd
[08:32:50]<mstenta[m]>maybe this one was edited/corrupted after the logs were created?
[08:33:10]<mstenta[m]>(that's one of the benefits of cloning area geometry to logs! backups :-) )
[08:36:44]<botlfarm[m]>perfect. deleting that worked. now I can get in and edit it. Thanks!
[08:37:18]<botlfarm[m]>or more importantly continue the 2.x migration
[08:39:01]<mstenta[m]>botlfarm: i am days away from releasing alpha3 FYI!
[08:39:31]<mstenta[m]>so maybe plan accordingly ;-)
[08:40:08]<mstenta[m]>still worthwhile to practice migrating right now - but plan to reinstall and re-migrate once that is released too
[08:40:19]<botlfarm[m]>Excellent. I mainly just wanted to see how the migration would work now that im in a linode server.
[08:40:27]<mstenta[m]>alpha3 will probably be the last alpha before beta1 - and *may* end up being "stable" in that regard
[08:40:37]<mstenta[m]>a lot of the major changes are done, or will be for alpha3
[08:41:08]<mstenta[m]>oh are you using sensors?
[08:41:29]<botlfarm[m]>I do have a handful of temp sensors
[08:42:03]<mstenta[m]>if so, i might recommend waiting to test the sensor data migration until after alpha3
[08:42:04]<mstenta[m]>paul121 refactored the migration to be MUUUUUUCH faster
[08:42:08]<mstenta[m]>(a big db with lots of data would take 8+ hours to migrate before - now it's minutes)
[08:42:45]<botlfarm[m]>good call
[08:43:23]<mstenta[m]>if you just leave the `farm_sensor` module turned off then the migration won't run
[08:43:47]<mstenta[m]>(more specifically the `farm_sensor_listener` module... you can actually leave `farm_sensor` on and migrate the `sensor` assets without the data)
[08:44:06]<mstenta[m]>(`farm_sensor_listener` will enable the data migration)
[08:44:51]<mstenta[m]>on a related note... i'm adding some documentation right now about migrating sensor data specifically to the migration docs
[08:45:09]<mstenta[m]>and how to limit "downtime" of your sensor data streaming, during migration, if that's important
[08:45:44]<mstenta[m]>in either case, be sure to follow the updated migration docs once alpha3 is released... there are a few minor differences
[08:46:14]<mstenta[m]>notably, we are adding a single `farm_migrate:import` drush command, which will run all the migration groups for you, so you don't have to do them individually
[08:46:19]<botlfarm[m]>I honestly just added sensors to farmos for the fun of it. I never actually look at them. Looking now it looks like they stopped updating about a month ago. oops. I will probably just start fresh in 2.x
[08:46:41]<mstenta[m]>ah well that makes things simpler haha :-)
[10:18:11]<symbioquine[m]><mstenta[m]> "paul121 refactored the migration..." <- Is that just for the sensors part of the migration?
[10:19:15]<mstenta[m]>oh but that reminds me symbioquine i know you had some automated migration testing code... you will need to make a few small changes for alpha3
[10:21:06]<symbioquine[m]>I plan to retest that migration/automation soon...
[10:21:20]<mstenta[m]>well for one... maybe you can just simplify completely... we added a `drush farm_migrate:import` command
[10:21:28]<mstenta[m]>this automatically runs all migration groups in the correct order
[10:21:34]<mstenta[m]>also there is `drush farm_migrate:rollback`
[10:21:38]<symbioquine[m]>ah, nice!
[10:22:03]<mstenta[m]>you *may* need to increase the `memory_limit` of Drush... i am documenting how to do that in the migration docs right now
[10:22:23]<mstenta[m]>i only ran into an issue with sensor data though, so maybe you won't need to - but it's kinda nice to give php cli a bit more memory anyway
[10:22:50]<mstenta[m]>other than that, i renamed `farm_migrate_reference` group to `farm_migrate_asset_parent`
[10:22:59]<mstenta[m]>and resolved the rollback issues
[10:24:12]<mstenta[m]>there are two other migration changes happening before alpha3 (almost merged): material type terms + quantities, and data stream migration improvement
[10:28:47]<mstenta[m]>> other than that, i renamed `farm_migrate_reference` group to `farm_migrate_asset_parent`
[10:28:47]<mstenta[m]>(i also changed WHEN this group runs... after asset/area migrations, instead of the very end, but it doesn't really matter)